Skip to content
dbexplore

Question: Vacuum, bloat and wraparound

Can I turn autovacuum off?

Answered in the first paragraph. Last updated .

You can, and it is almost always the wrong lever. Switching the daemon off does not stop vacuuming: the documentation is explicit that the system still launches workers when it has to, to keep transaction ids from wrapping around. What you have turned off is the routine schedule that was holding the rest of the tables in shape, and the emergency pass that remains is the most disruptive form of the work.

What keeps running, and what quietly stops

The wraparound protection survives, because the alternative is a cluster that refuses to accept writes. It arrives on its own schedule, on whichever table crosses the age limit first, and it is not paced for your traffic. Deferring maintenance until then converts many small passes into one large one at a moment nobody picked. Freezing and the frozen id is the counter that decides when.

What stops is everything else. Space inside tables is never marked reusable, so files only grow. The visibility bookkeeping that lets scans skip pages goes stale, and plans that depended on it get slower for no visible reason. And the automatic analyze stops with it, which is the part people forget: the planner starts working from row counts that describe a table you no longer have.

There is a second-order effect worth naming. Once the age gets dangerous the server abandons its own pacing entirely and vacuums flat out, which is the failsafe. That is the behaviour you have chosen when you disable the daemon and wait.

The three complaints behind the question, and their real fixes

It is using too much I/O. The pacing is a pair of settings, a delay and a budget, and lowering the cost of a page read or raising the budget changes the throughput directly without changing whether the work happens.

It never finishes on the big table. That is a memory and concurrency problem rather than a scheduling one, and making vacuum run faster covers the three settings that move it.

It runs at the wrong time. Thresholds are per table, so a table that should only be touched overnight can be given its own trigger while the rest of the schema keeps the default.

There is one legitimate use of the switch, and it is narrow: turning it off for a single table you vacuum yourself on a schedule you control, with an alarm on that table’s age so the arrangement fails loudly rather than silently. Autovacuum and table bloat covers the per-table thresholds worth setting, and what dead rows do to a file while nothing is clearing them.

Put every Postgres you run on autopilot.

We onboard teams in small batches. Tell us about your fleet and we will reach out when a seat opens. One email, no drip campaign.