The Good, The Bad, and The Bloated: An Autovacuum Story
summary
A production cluster becomes unusable when 3 autovacuum workers vs 1,500 tables lets large tables hog all workers, causing runaway bloat and a midnight dump/restore. Practical fixes: tune cluster and per-table settings (set analyze_scale_factor ≈ half of vacuum_scale_factor), use partitioning, drop unused indexes, and reindex when indexes bloat; beware vacuum_full takes an exclusive lock. Note defaults: vacuum_cost_limit 200 → raised 25× in that case, and PG18 adds 100,000,000 autovacuum threshold and autovacuum_worker_slots = 16.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:05Why autovacuum matters
- 7:17How autovacuum works
- 9:03The bloated disaster story
- 12:38Tuning autovacuum strategies
- 24:54Monitoring bloat and activity
- 33:13Conclusion and key takeaways
- 38:46Q&A
related talks
55mUnderstanding Autovacuum
59mHow Autovacuum Goes Wrong: And Can We Please Make It Stop Doing That?
47mAutoVacuum - Tuning and Monitoring
49mUnderstanding and Fixing Autovacuum
25mUnderstanding & Managing Postgres Table Bloat
32mOptimizing autovacuum: PostgreSQL’s vacuum cleaner
27mMaintaining Large Tables in PostgreSQL
19mVacuuming Enhancements in PostgreSQL 18: Faster, Smarter, More Predictable