select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / VACUUMING

autovacuum_max_workers

Read PG 18 manual ↗

Specifies the maximum number of autovacuum processes (other than the autovacuum launcher) that may be running at any one time.

Type
integer
Context
sighup
Measured default
3
Unit
Metadata snapshot
18

Definition PG 18 manual

Specifies the maximum number of autovacuum processes (other than the autovacuum launcher) that may be running at any one time. The default is 3. This parameter can only be set in the postgresql.conf file or on the server command line.

Note that a setting for this value which is higher than autovacuum_worker_slots will have no effect, since autovacuum workers are taken from the pool of slots established by that setting.

Measured default history
Version intervalDefault
9.0 – 193
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

The launcher starts workers across databases up to this limit. A worker can process one table at a time, several workers may operate in the same database, and these processes do not consume max_connections slots.

In PostgreSQL 18, autovacuum workers are drawn from autovacuum_worker_slots, so setting this value above the slot count has no effect. The local fact matrix also records a context change: PG10-17 required server start, while PG18 makes the setting reloadable.

Autovacuum cost limits are normally balanced among active workers. Raising only the worker count therefore improves concurrency and queueing, but does not necessarily multiply the total permitted maintenance I/O rate.

Operational considerations

A value above autovacuum_worker_slots is ineffective on PostgreSQL 18.

More workers can amplify I/O latency even when backlog improves.

Raising workers alone may not raise aggregate cost-based vacuum throughput.

A few very large tables can occupy all workers and delay unrelated databases.

Changing it on PG10-17 requires restart; PG18 behavior is reloadable.

Workload guidance

OLAP: Large relations can occupy workers for long periods, so extra workers may reduce backlog across databases. Pair any increase with explicit maintenance windows and cost-limit review.

OLTP: Increase gradually only when eligible tables wait too long and storage has headroom. Check worker saturation, vacuum duration, I/O latency, and autovacuum_worker_slots together.

SMALL: Two or three workers are usually a sensible starting range. Prefer fewer concurrent workers over disabling autovacuum on a constrained host.

Version history 4
  1. PG 17 → 18changed
  2. PG 9.5 → 9.6changed
  3. PG 9.4 → 9.5changed
  4. PG 9.0 → 9.1changed

Related entries

Further reading

Definition snapshot: english-manuals:9c9a3b86e17e532e589e8a48523… · English manual source