autovacuum_vacuum_insert_score_weight

Definition PG 20 devel manual

Specifies the scaling factor of the vacuum insert threshold component of the score used by autovacuum for prioritization purposes. The default is 1.0. This parameter can only be set in the postgresql.conf file or on the server command line. See Section 24.1.6.1 for more information.

How it works

PostgreSQL describes autovacuum_vacuum_insert_score_weight as follows: “Scaling factor of vacuum insert 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 insert-driven 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_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.

Operational considerations

Treating the measured boot_val for autovacuum_vacuum_insert_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.

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.