autovacuum_vacuum_score_weight
Fact — official short description: “Scaling factor of vacuum score for autovacuum prioritization.”
Identity
Lifecycle
| Fact | Value |
|---|---|
| First observed | PG19 Beta 3 |
| Present in | PG19 Beta 3 |
| Removed in | No |
| Introduction commit | d7965d65fc5b — Add rudimentary table prioritization to autovacuum. |
| Commit date | 2026-03-27 |
| Discussion | thread 1 |
Default history
| Versions | Raw boot_val |
Unit | Human value |
|---|---|---|---|
| PG19 Beta 3 | 1 |
— | 1 |
How it works
PostgreSQL describes autovacuum_vacuum_score_weight as follows: “Scaling factor of vacuum score for autovacuum prioritization.” 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.
PostgreSQL 19 scores every eligible table and sorts work by the maximum weighted component. This parameter multiplies the updated/deleted-tuple vacuum pressure component: values above 1 raise its scheduling influence, values between 0 and 1 reduce it, and setting every score weight to 0 restores the pre-19 catalog-order strategy. pg_stat_autovacuum_scores exposes the components for inspection.
Read it together with autovacuum_freeze_score_weight, autovacuum_multixact_freeze_score_weight, autovacuum_vacuum_insert_score_weight, autovacuum_analyze_score_weight. 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.
Tuning advice
Advice. These are workload-specific starting points and must be validated with measurements.
| Workload | Guidance |
|---|---|
| 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. |
| 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. |
| Small nodes | 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. |
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 | — | — |
Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG19 Beta 3 unmodified; OLAP: PG19 Beta 3 unmodified; CRIT: PG19 Beta 3 unmodified; TINY: PG19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.
Common pitfalls
- Treating the measured boot_val for autovacuum_vacuum_score_weight 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.
Related parameters
autovacuum_freeze_score_weight · autovacuum_multixact_freeze_score_weight · autovacuum_vacuum_insert_score_weight · autovacuum_analyze_score_weight · autovacuum_max_workers · autovacuum_naptime
References
- PostgreSQL 19 Beta 3 — autovacuum_vacuum_score_weight
- PostgreSQL 19 release notes
- Machine-readable GUC export