Horton
Menu

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Lukas Fittl <lukas@fittl.com>
Cc: David Geier <geidav.pg@gmail.com>, Jakub Wartak <jakub.wartak@enterprisedb.com>, Hannu Krosing <hannuk@google.com>, Robert Haas <robertmhaas@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, vignesh C <vignesh21@gmail.com>, Michael Paquier <michael@paquier.xyz>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, Maciek Sakrejda <m.sakrejda@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-02-13T00:41:22Z
Lists: pgsql-hackers 
Hi,

On 2026-02-12 08:05:27 -0800, Lukas Fittl wrote:
> On master (88327092ff0), I'm getting 23.54 ns from pg_test_timing - vs
> with 0002 applied, this slows to 25.74 ns. I've tried to see if the
> "unlikely(..)" we added in pg_ticks_to_ns is the problem (since in the
> clock_gettime() case we'd always be running into that branch due to
> the size of the nanoseconds value), but no luck - I think the extra
> multiplication/division itself is the problem.
> 
> Any ideas how we could do this differently?

The problem looks to be that you're going to take the slowpath when using
clock_gettime(), unless you booted within the last three days, because
pg_test_timing() is doing

		INSTR_TIME_SET_CURRENT(temp);
		cur = INSTR_TIME_GET_NANOSEC(temp);

Which will require reducing time-since-boot in nanoseconds (with
CLOCK_MONOTONIC) via pg_ticks_to_ns() overflow logic, as the way
max_ticks_no_overflow is set in 0001, it'll overflow after a few days of
runtime.

This can largely be addressed by keeping prev and cur in the instr_time
domain and only converting the difference to nanoseconds.


I wonder if pg_test_timing should have a small loop with a fixed count to
determine the timing without all the overhead the existing loop has...

Greetings,

Andres Freund

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_test_timing: Show additional TSC clock source debug info

  2. instrumentation: Avoid CPUID 0x15/0x16 for Hypervisor TSC frequency

  3. pg_test_timing: Also test RDTSC[P] timing, report time source, TSC frequency

  4. Allow retrieving x86 TSC frequency/flags from CPUID

  5. instrumentation: Standardize ticks to nanosecond conversion method

  6. instrumentation: Use Time-Stamp Counter on x86-64 to lower overhead

  7. Check for __cpuidex and __get_cpuid_count separately

  8. pg_test_timing: Reduce per-loop overhead

  9. Refactor handling of x86 CPUID instructions

  10. instrumentation: Drop INSTR_TIME_SET_CURRENT_LAZY macro

  11. Rename pg_crc32c_sse42_choose.c for general purpose

  12. Zero initialize uses of instr_time about to trigger compiler warnings

  13. instr_time: Represent time as an int64 on all platforms

  14. Add 250c8ee07ed to git-blame-ignore-revs