autovacuum_max_workers

For DBAs and operators

Since PostgreSQL 18 this is a reload setting, bounded by autovacuum_worker_slots (reserved at startup). A value above the slots has no effect; the server warns WARNING: "autovacuum_max_workers" (20) should be less than or equal to "autovacuum_worker_slots" (16). Before 18 it needed a restart.

The cost-limit trap

The cost budget autovacuum_vacuum_cost_limit (or vacuum_cost_limit) is shared among all running workers (tables with their own per-table cost settings are excluded from balancing). Going from 3 to 10 workers without raising the limit makes each worker about three times slower; total throughput stays the same. Raise both together.

When to raise it

• Many databases or thousands of tables, and pg_stat_activity constantly shows all workers busy while tables wait (their n_dead_tup keeps growing).
• A few giant tables hog all workers for hours: raising workers lets small hot tables be cleaned meanwhile.

SELECT count(*) FROM pg_stat_activity WHERE backend_type = 'autovacuum worker';
SELECT p.pid, p.relid::regclass, p.phase, p.heap_blks_scanned, p.heap_blks_total
  FROM pg_stat_progress_vacuum p;

Each worker can use up to autovacuum_work_mem (or maintenance_work_mem) for dead tuple IDs, so more workers also means more memory.

How to change it

Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().