autovacuum

Definition PG 18 manual

Controls whether the server should run the autovacuum launcher daemon. This is on by default; however, track_counts must also be enabled for autovacuum to work. This parameter can only be set in the postgresql.conf file or on the server command line; however, autovacuuming can be disabled for individual tables by changing table storage parameters.

Note that even when this parameter is disabled, the system will launch autovacuum processes if necessary to prevent transaction ID wraparound. See Section 24.1.5 for more information.

How it works

When enabled, one launcher coordinates worker processes across databases. Workers use cumulative table-change statistics, so track_counts must also be enabled, and they run VACUUM or ANALYZE when a table crosses the relevant thresholds.

Ordinary vacuum triggers react to inserted, updated, and deleted tuples. Separately, PostgreSQL can launch anti-wraparound autovacuums even when this switch is off, because allowing old transaction IDs or multixact IDs to wrap would threaten correctness.

Most trigger and cost settings can be overridden per table through storage parameters. Temporary tables are outside autovacuum's reach, and partitioned parent tables can still need manual ANALYZE even though their partitions are processed normally.

Operational considerations

Turning it off does not disable emergency anti-wraparound vacuuming.

track_counts must be on for ordinary autovacuum decisions to work.

Long transactions and stale replication slots can prevent cleanup even when workers run successfully.

Autovacuum does not analyze partitioned parent tables solely because their partitions changed.

Temporary tables require maintenance from the owning session.

Workload guidance

OLAP: Keep it on for safety, but coordinate it with bulk-load windows. Run explicit ANALYZE after large loads and on partitioned parents when planner statistics must be immediately current.

OLTP: Keep it on. Tune busy tables individually, then watch dead tuples, autovacuum duration, canceled workers, and XID age before changing global aggressiveness.

SMALL: Leave the default on. Reducing worker count or per-table aggressiveness is safer than disabling the launcher merely to save a small amount of background activity.