autovacuum_vacuum_cost_delay

Definition PG 18 manual

Specifies the cost delay value that will be used in automatic VACUUM operations. If -1 is specified, the regular vacuum_cost_delay value will be used. If this value is specified without units, it is taken as milliseconds. The default value is 2 milliseconds. This parameter can only be set in the postgresql.conf file or on the server command line; but the setting can be overridden for individual tables by changing table storage parameters.

How it works

Vacuum cost delay in milliseconds, for autovacuum. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

These values govern cost throttling for autovacuum workers; -1 inherits vacuum_cost_delay or vacuum_cost_limit respectively. With multiple active workers, the autovacuum cost budget is balanced among them, so a per-worker reading is not simply multiplied by concurrency.

Monitor and change autovacuum_vacuum_cost_delay together with vacuum_cost_delay, vacuum_cost_limit, vacuum_cost_page_hit. Validate on the relevant server role and real workload, then use its sighup 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 autovacuum_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.