track_cost_delay_timing

track_cost_delay_timing — Collects timing statistics for cost-based vacuum delay. Observed in PG18–19 Beta 3; its last measured boot default is off in PG19 Beta 3, with superuser context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Collects timing statistics for cost-based vacuum delay.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuesuperuser: Settable at runtime by a superuser
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueStatistics / Cumulative Query and Index Statistics: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG18
Present in	PG18–19 Beta 3
Removed in	No
Introduction commit	`bb8dff9995f2` — Add cost-based vacuum delay time to progress views.
Commit date	2025-02-11
Discussion	thread 1

Default history

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

How it works

track_cost_delay_timing measures time actually spent in cost-based VACUUM and ANALYZE delay. The result appears in progress views, verbose command output, and eligible autovacuum logs.

Collection repeatedly reads the operating-system clock and can have platform-dependent overhead. It does not enable vacuum delay or alter vacuum_cost_* policy.

The metric helps distinguish useful work from intentional throttling. pg_test_timing can measure clock-read overhead before enabling it widely. Its superuser context permits an authorized session change without a server restart.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Enable it when operators need to distinguish VACUUM or ANALYZE work from intentional cost-delay sleep. Measure clock-read overhead with pg_test_timing and under autovacuum load; it is a boolean and does not size or enable cost-based delay itself.
OLAP	It is useful when long maintenance overlaps analytical work and throttle time must be quantified. Compare reported delay time with maintenance duration and foreground latency, then keep it on only if the evidence is used operationally.
Small nodes	Leave off unless vacuum-delay diagnostics are needed and clock reads are cheap on the platform. Enabling it does not make maintenance faster or slower by policy; vacuum_cost_* settings remain separate.

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	`on`	different	`'on'`
CRIT	`on`	different	`'on'`
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 = on (dcs); CRIT: PG18–19 Beta 3 = on (dcs); TINY: PG18–19 Beta 3 unmodified. Advice, pending human review — Editorial inference, pending maintainer review: The OLAP/crit-only switch is intended to expose time spent in vacuum/analyze cost delays where long maintenance or critical observability justifies clock overhead.

Common pitfalls

Assuming the switch enables cost-based vacuum delay rather than only timing existing delay.
Ignoring platform-dependent clock-read overhead instead of measuring with pg_test_timing.
Looking for the metric without enabling the relevant progress, verbose, or autovacuum-log output.
Treating the boolean as a duration or buffer-size parameter.

vacuum_cost_delay · autovacuum_vacuum_cost_delay · log_autovacuum_min_duration · track_io_timing · vacuum_buffer_usage_limit