Skip to content

autovacuum_worker_slots

autovacuum_worker_slots — Sets the number of backend slots to allocate for autovacuum workers. Observed in PG18–19 Beta 3; its last measured boot default is 16 in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.
Note

Fact — official short description: “Sets the number of backend slots to allocate for autovacuum workers.”

Identity

Type , Valueinteger
Upstream pg_settings type
Context , Valuepostmaster
Requires a server restart
Unit , Value
Raw unit
Range , Value1262143
Raw limits in the last observed version
Enum values , Value
— for non-enum types
Category , ValueVacuuming / Automatic Vacuuming
Upstream classification
Latest boot value , Value16
16

Lifecycle

Fact Value
First observed PG18
Present in PG18–19 Beta 3
Removed in No
Introduction commit c758119e5bfb — Allow changing autovacuum_max_workers without restarting.
Commit date 2025-01-06
Discussion thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions Raw boot_val Unit Human value
PG18–19 Beta 3 16 16

How it works

Sets the number of backend slots to allocate for autovacuum workers. The value is fixed when the server starts, so changing it requires a restart.

PG18 separates the startup allocation of backend slots for autovacuum workers from the active concurrency limit autovacuum_max_workers. The slots are reserved at startup so the worker limit can be reloaded within that allocation.

Monitor and change autovacuum_worker_slots together with autovacuum, autovacuum_naptime, autovacuum_max_workers. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload Guidance
OLTP Tune autovacuum_worker_slots from table size, change rate, and maintenance SLA, using per-table thresholds for large/hot relations. Observe trigger intervals, dead tuples, and ANALYZE/VACUUM duration.
OLAP Run explicit ANALYZE/VACUUM after bulk loads instead of waiting only for proportional triggers; plan freezing and visibility-map advancement separately for append-only partitions.
Small nodes Start with upstream or the measured Pigsty matrix value. Fixed thresholds dominate on small tables; after changes, confirm worker and I/O headroom.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template Effective value Versus upstream boot Source expression
OLTP Unmodified
OLAP Unmodified
CRIT Unmodified
TINY Unmodified
Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG18–19 Beta 3 unmodified; OLAP: PG18–19 Beta 3 unmodified; CRIT: PG18–19 Beta 3 unmodified; TINY: PG18–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

  • 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.

autovacuum · autovacuum_naptime · autovacuum_max_workers · autovacuum_work_mem · track_counts · autovacuum_analyze_scale_factor

References