vacuum_cost_limit

Definition PG 18 manual

This is the accumulated cost that will cause the vacuuming process to sleep for vacuum_cost_delay. The default is 200.

How it works

Vacuum cost amount available before napping. It can be changed at session scope, so different sessions may observe different behavior.

VACUUM accumulates virtual cost for page hits, misses, and dirties; after the balance reaches vacuum_cost_limit it sleeps for vacuum_cost_delay and resets. This is coarse I/O pacing rather than an exact bandwidth cap, and the wraparound failsafe bypasses throttling.

Monitor and change vacuum_cost_limit together with vacuum_cost_delay, vacuum_cost_page_hit, vacuum_cost_page_miss. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Changing the global value while a table storage parameter overrides it.

Treating reltuples and cumulative change statistics as exact real-time counts.

Blaming a threshold without checking long transactions, replication slots, and worker saturation.

Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Workload guidance

OLAP: During post-load windows, a larger budget or shorter delay can improve maintenance throughput, but verify that scans do not starve queries/imports. Failsafe activation means normal pacing already failed.

OLTP: Tune vacuum_cost_limit from autovacuum duration, dead-tuple growth, and foreground I/O latency together. Prefer per-table overrides for hotspots; global throttling must not let cleanup fall permanently behind.

SMALL: Keep conservative defaults. On slow disks, lowering concurrency or overriding one table is usually more controllable than making the delay arbitrarily large.