track_wal_io_timing

track_wal_io_timing — Collects timing statistics for WAL I/O activity. Observed in PG14–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 WAL I/O activity.”

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	PG14
Present in	PG14–19 Beta 3
Removed in	No
Introduction commit	`ff99918c625a` — Track total amounts of times spent writing and syncing WAL data to disk.
Commit date	2021-03-09
Discussion	thread 1

Default history

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

How it works

track_wal_io_timing measures wait time for WAL I/O and exposes it under the wal object in pg_stat_io and pg_stat_get_backend_io(). It is independent of ordinary database I/O timing.

Collection repeatedly reads the operating-system clock and can add platform-dependent overhead. pg_test_timing measures clock-read cost, while workload tests reveal aggregate impact.

It does not change wal_sync_method, durability, or WAL throughput. Pairing it with track_io_timing separates WAL waits from relation and temporary-file I/O. 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 WAL write and sync waits must be separated from relation I/O during commit-latency analysis. Measure platform clock overhead and correlate the counters with synchronous_commit, wal_sync_method, and storage behavior.
OLAP	Read-heavy analytics may gain little from WAL timing, while bulk loads and refresh jobs can benefit substantially. Enable it for the write phases that use the evidence rather than because the workload is labeled OLAP.
Small nodes	Keep off unless WAL latency is an active diagnostic need and clock reads are inexpensive. Pair it with track_io_timing only when both WAL and non-WAL wait separation is useful.

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	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG14–19 Beta 3 unmodified; OLAP: PG14–19 Beta 3 unmodified; CRIT: PG14–19 Beta 3 unmodified; TINY: PG14–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Expecting WAL timing to include relation and temporary-file I/O measured by track_io_timing.
Treating elapsed WAL waits as pure device service time.
Assuming the switch changes durability, wal_sync_method, or WAL throughput.
Enabling it without measuring clock-read overhead on the production platform.

track_io_timing · wal_sync_method · synchronous_commit · track_counts · stats_fetch_consistency