Vacuuming Enhancements in PostgreSQL 18: Faster, Smarter, More Predictable
summary
Postgres 18 adds a practical set of VACUUM changes: an asynchronous I/O subsystem (io_method=worker, io_workers default 3, scalable to ~12) that overlaps reads with processing and cuts heap-scan latency on high‑latency storage; dynamic autovacuum scaling via autovacuum_worker_slots so autovacuum_max_workers changes without restart; a hard dead‑tuple cap autovacuum_vacuum_max_threshold (example 50M) to avoid silent bloat; eager freezing to prevent wraparound I/O storms; recursive VACUUM/ANALYZE for partitions; and new per‑table timing and I/O counters for tuning.
AI-written summary · about
chapters (13)
- 0:00Music & introduction
- 1:36What’s new in PG18 vacuuming
- 2:02Pain points before PostgreSQL 18
- 3:14Fixes introduced in PG18
- 4:17Asynchronous I/O for faster vacuum
- 6:05Dynamic autovacuum scaling explained
- 8:15Dead tuple cap on large tables
- 9:50Eager freezing to prevent I/O spikes
- 11:34Partitioned tables: auto vacuum & analyze
- 13:17Vacuum truncation and replica impact
- 14:54Observability and new metrics
- 17:20Key takeaways and improvements
- 18:10Resources, blog, and closing
related talks
47mImproved Freezing in Postgres Vacuum: From Idea to Commit
55mUnderstanding Autovacuum
52mBoosting Typical Query Patterns: PostgreSQL 18's Performance Enhancements
17mThe Evolution of Postgres Performance
32mOptimizing autovacuum: PostgreSQL’s vacuum cleaner
48mInside Postgres: why VACUUM matters
49mA Detailed Understanding of MVCC and Autovacuum Internals in PostgreSQL 14
47mAutoVacuum - Tuning and Monitoring