Christophe Pettus: All Your GUCs in a Row: autovacuum
Autovacuum is a critical PostgreSQL background process responsible for reclaiming storage and maintaining performance by removing dead tuples and updating statistics. Disabling it leads to severe issues such as table and index bloat, stale query plans, and eventual database outages due to transaction ID wraparound. The recommended approach is to tune autovacuum parameters rather than disable it, except in specific bulk-loading scenarios.
- ▪Autovacuum automatically runs VACUUM and ANALYZE to manage dead tuples and update planner statistics.
- ▪Disabling autovacuum causes heap and index bloat, stale statistics, failed index-only scans, and risks MultiXact and transaction ID wraparound.
- ▪Performance issues attributed to autovacuum should be addressed by tuning parameters like autovacuum_vacuum_cost_limit, not by turning it off.
- ▪TOAST tables, which store large column values, also bloat when autovacuum is disabled, consuming disk space silently.
- ▪Global autovacuum disable is only justified during bulk data loads, with immediate re-enablement afterward.
Opening excerpt (first ~120 words) tap to expand
1 May 2026 3 min read Categories: PostgreSQL All Your GUCs in a Row: autovacuum autovacuum is a boolean. Default on, context sighup. Set it to off for any meaningful length of time and you have purchased a tour of every PostgreSQL failure mode worth knowing about, in escalating order, at no extra charge. Let me describe the tour. The autovacuum launcher and its workers run VACUUM and ANALYZE against tables based on accumulated activity. It is the single most important background process in the database. People nevertheless turn it off, usually because vacuum is “causing performance problems,” because the table is “write-only,” or because they read a forum post written by someone who lost an argument with PostgreSQL in 2008. None of these reasons survive contact with the consequences.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Postgr.
Discussion
0 commentsMore from Postgr
