Horton
Menu

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Hannu Krosing <hannuk@google.com>

View thread
From: Hannu Krosing <hannuk@google.com>
To: Lukas Fittl <lukas@fittl.com>
Cc: Andres Freund <andres@anarazel.de>, David Geier <geidav.pg@gmail.com>, Jakub Wartak <jakub.wartak@enterprisedb.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-13T14:42:36Z
Lists: pgsql-hackers 
On Fri, Feb 13, 2026 at 5:11 AM Lukas Fittl <lukas@fittl.com> wrote:
>
> On Thu, Feb 12, 2026 at 4:41 PM Andres Freund <andres@anarazel.de> wrote:
> > 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...
>
> I agree that using a fixed count in pg_test_timing would be helpful to
> measure just the timing gathering itself, vs the translation into
> nanoseconds.

I haven't looked at the code here yet, but when using plain rdtsc on
modern CPUs one sees much more overhead from just the fact that the
code is there than from calling the rdtsc instruction, and the
overhead can vary by orders of magnitude based on how complex the work
is that is timed.

I discovered this when I timed the (then-)new dead tid lookups in the
Vacuum in Pg 17 and saw significantly larger overhead per lookup when
the lookups themselves were slower, i.e. a case where the lookups were
done in random order (inded was on  created on a column filled with
random())

So while just a tight loop of N million rtdsc calls will give you the
lower limit, it is likely not very representative of actual overhead.

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