autovacuum_max_parallel_workers

Definition PG 20 devel manual

Sets the maximum number of parallel workers that can be used by a single autovacuum worker to process indexes. This limit applies specifically to the index vacuuming and index cleanup phases (for the details of each autovacuum phase, please refer to Table 27.52). The actual number of parallel workers is further limited by max_parallel_workers. This is the per-autovacuum worker equivalent of the PARALLEL option of the VACUUM command. Setting this value to 0 disables parallel vacuum during autovacuum. The default is 0.

How it works

PostgreSQL describes autovacuum_max_parallel_workers as follows: “Maximum number of parallel workers that can be used by a single autovacuum worker.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

The limit applies per autovacuum worker and only to index vacuuming and index-cleanup phases. Zero disables parallel autovacuum; the actual count is also capped by max_parallel_workers, while each participating worker consumes CPU and maintenance memory.

Read it together with autovacuum_max_workers, autovacuum_worker_slots, max_parallel_workers, maintenance_work_mem. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for autovacuum_max_parallel_workers as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports sighup context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Workload guidance

OLAP: Batch-heavy systems can benefit from prioritizing the largest maintenance debt or parallelizing index cleanup, but benchmark I/O saturation, maintenance memory, worker contention, and completion time across the whole maintenance window.

OLTP: Start at the upstream default and use pg_stat_autovacuum_scores, table churn, freeze age, queueing, and foreground latency to justify a change. Protect wraparound work and avoid letting a busy-table preference starve quieter tables.

SMALL: Keep weights and parallelism conservative. One extra worker can be a large share of CPU, RAM, and storage queue depth; first fix thresholds and ensure autovacuum has enough time to finish.