track_cost_delay_timing
Read PG 18 manual ↗Enables timing of cost-based vacuum delay (see Section 19.10.2).
- Type
- bool
- Context
- superuser
- Measured default
- off
- Unit
- —
- Metadata snapshot
- 18
Definition PG 18 manual
Enables timing of cost-based vacuum delay (see Section 19.10.2). This parameter is off by default, as it will repeatedly query the operating system for the current time, which may cause significant overhead on some platforms. You can use the pg_test_timing tool to measure the overhead of timing on your system. Cost-based vacuum delay timing information is displayed in pg_stat_progress_vacuum, pg_stat_progress_analyze, in the output of VACUUM and ANALYZE when the VERBOSE option is used, and by autovacuum for auto-vacuums and auto-analyzes when log_autovacuum_min_duration is set. Only superusers and users with the appropriate SET privilege can change this setting.
Measured default history
| Version interval | Default |
|---|---|
| 18 – 19 | off |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
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.
Operational considerations
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.
Workload guidance
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.
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.
SMALL: 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.
Version history 1
- PG 17 → 18added
Related entries
Further reading
Definition snapshot: english-manuals:1246eb234815ccebd1ca3d764ab… · English manual source