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: Andres Freund <andres@anarazel.de>
Cc: 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-03-03T18:22:42Z
Lists: pgsql-hackers 
On Tue, Mar 3, 2026 at 9:09 AM Andres Freund <andres@anarazel.de> wrote:
> On 2026-03-03 02:29:06 -0800, Lukas Fittl wrote:
> > - Added support for HyperV hypervisor by reading the TSC frequency
> > MSR. This allows Azure Linux VMs to work as well, and in my test gives
> > a similar speed up with RDTSC like reported on AWS. Only annoyance is
> > that to enable it you have to make /dev/cpu/0/msr readable ("setcap
> > cap_sys_rawio=ep" on the binary that accesses it + give the user/group
> > access to the device file)
>
> I rather doubt that giving even just read access to MSRs to unprivileged
> userspace processes is a good idea.

Yeah, that's fair - the interface here is rather crude, and I agree
that MSR access is problematic for non-root.

> But if we read files anyway, wouldn't just using
>   /sys/devices/system/cpu/cpu0/cpufreq/base_frequency
> work?

I tested this just now on an Azure VM (Standard D2s v3), and its
close, but unfortunately CPU frequency doesn't match the TSC frequency
(cpuinfo_max_freq is 2800000, scaling_cur_freq is 2496279, and TSC
frequency via MSR is 2793438 -- note that I didn't have base_frequency
on this VM). My understanding is that the TSC clock is virtualized in
HyperV and does not directly match the CPU frequency.

I'm also happy to take this out again - maybe we can get the
HyperV/Azure Linux folks to improve the Kernel side here to pass down
the TSC frequency without needing the MSR, and just not support it for
now.

An alternate idea could be to allow overriding the TSC frequency via a
GUC - then one could use the root user (or a setuid program) to get
the TSC frequency on Azure/HyperV via the MSR and pass it to Postgres
at start. But not sure that's worth the trouble, since it won't help
with environments that don't have a reliable TSC (e.g. Virtualbox, I
think).



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