Lukas Fittl: Waiting for Postgres 19: Reduced Timing Overhead for EXPLAIN ANALYZE with RDTSC

Why It Matters

Reducing timing overhead restores accurate query‑performance data, enabling broader use of auto_explain.log_timing and more reliable tuning for production PostgreSQL deployments.

Key Takeaways

• RDTSC cuts EXPLAIN ANALYZE timing overhead by ~50% versus RDTSCP.
• New `timing_clock_source` parameter lets users select system or TSC clock.
• Default in Postgres 19 automatically uses RDTSC for low‑overhead profiling.
• Enables `auto_explain.log_timing` in more workloads without skewing results.
• Release slated for September‑October 2026 after May beta.

Pulse Analysis

PostgreSQL’s internal instrumentation has long relied on the Linux clock_gettime call, which resolves to the RDTSCP instruction on modern x86‑64 CPUs. While RDTSCP provides serialized timestamps, it forces the CPU to wait for prior instructions, inflating the cost of each timing probe. In large‑scale queries, this overhead can double the apparent execution time, prompting DBAs to disable timing in EXPLAIN ANALYZE and lose valuable insight into query performance.

The upcoming PostgreSQL 19 release addresses this bottleneck by adding a new configuration option, timing_clock_source, that lets the server switch to the raw RDTSC instruction for timing measurements. RDTSC reads the processor’s time‑stamp counter without serialization, cutting the per‑probe cost by roughly half. Benchmarks on a 50‑million‑row table show EXPLAIN ANALYZE overhead dropping from about 20‑25% to under 10% when RDTSC is used, and the default behavior now automatically selects the fastest source for each workload. This change also revitalizes the auto_explain module, allowing log_timing to stay enabled without skewing the recorded runtimes.

For database administrators and performance engineers, the impact is immediate. More accurate timing data means finer‑grained tuning, better capacity planning, and confidence that observed latencies reflect real execution costs rather than instrumentation artifacts. The automatic fallback to the system clock preserves precision where needed, while the optional manual switch offers flexibility for specialized environments. As PostgreSQL 19 moves toward its September‑October 2026 GA, the reduced overhead positions the platform as an even more attractive choice for high‑throughput, latency‑sensitive applications.