vacuum_cost_delay

Definition PG 18 manual

The amount of time that the process will sleep when the cost limit has been exceeded. If this value is specified without units, it is taken as milliseconds. The default value is 0, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming.

When using cost-based vacuuming, appropriate values for vacuum_cost_delay are usually quite small, perhaps less than 1 millisecond. While vacuum_cost_delay can be set to fractional-millisecond values, such delays may not be measured accurately on older platforms. On such platforms, increasing VACUUM's throttled resource consumption above what you get at 1ms will require changing the other vacuum cost parameters. You should, nonetheless, keep vacuum_cost_delay as small as your platform will consistently measure; large delays are not helpful.

How it works

Vacuum cost delay in milliseconds. 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_delay together with vacuum_cost_limit, 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_delay 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.