Horton
Menu

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Lukas Fittl <lukas@fittl.com>

View thread
From: Lukas Fittl <lukas@fittl.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Andres Freund <andres@anarazel.de>, John Naylor <johncnaylorls@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>, David Geier <geidav.pg@gmail.com>
Date: 2026-04-07T00:06:36Z
Lists: pgsql-hackers 
Hi Zsolt,

On Mon, Apr 6, 2026 at 4:36 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>
> +uint64 max_ticks_no_overflow = 0;
>
> Could this be int64? It is based on PG_INT64_MAX, and it's only
> practical use is with a cast to int64.

Its intentionally uint64, per this comment above it:

 * Note we utilize unsigned integers even though ticks are stored as a signed
 * value to encourage compilers to generate better assembly, since we can be
 * sure these values are not negative.

In my earlier Compiler Explorer tests that did actually make a
difference for the generated assembly.

>
> > This allows the direct use of the Time-Stamp Counter (TSC) value retrieved
> > from the CPU using RDTSC/RDTSC instructions,
>
> Typo in commit message for 0003: RDTSC/RDTSC
>
> + else
> + printf(_("TSC clock source is not usable. Likely unable to determine
> TSC frequency. are you running in an unsupported virtualized
> environment?.\n"));
> +}
>
> Typo: are, ?.

Agreed those are typos. Since I know Andres is actively taking a look
at things right now I'll hold off on posting a new version for this,
but thanks for noting.

>
> -/* TSC specific logic */
> +/* Hardware clock specific logic (x86 TSC / AArch64 CNTVCT) */
>
> Shouldn't this ARM patch also update the documentation?

Yes, it should, but there are other open items for the ARM patch
(mainly the detection of different CPU core types causing different
CNTVCT frequencies needs to be OS agnostic), so the ARM patch is not
targeted for 19. Its just in this patch set to illustrate how we can
expand coverage for it later.



Thanks,
Lukas

--
Lukas Fittl

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