Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

On Mon, Feb 2, 2026 at 1:22 AM Jakub Wartak
<jakub.wartak@enterprisedb.com> wrote:
> > +#define CPUID_HYPERVISOR_VMWARE(words) (words[1] == 0x61774d56 && words[2] == 0x4d566572 && words[3] == 0x65726177) /* VMwareVMware */
> > +#define CPUID_HYPERVISOR_KVM(words) (words[1] == 0x4b4d564b && words[2] == 0x564b4d56 && words[3] == 0x0000004d)    /* KVMKVMKVM */
> ...
>
> When trying to understand this code I was thinking how it could be
> made smaller or less dependent on such low-level intrinsics, the only
> thing that came to my mind was launching systemd-detect-virt(1) via
> fork+execve, as after all we do have USE_SYSTEMD (for sd_notify(2) already
> consumed in backend/postmaster/postmaster.c) anyway.
>
> Sadly this path for checking VM-types seems like opening can of worms
> - they evolved lots of code to cover various other products,
> see e.g. in detect_vm() and that thing is not exported.
>
> Another way would be probably inquiring their D-Bus API, something like
> below command seems to work:
>    busctl get-property org.freedesktop.systemd1
> /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager
> Virtualization
>
> (that seems to be sd_bus_get_property_string(3)).
>
> It's not that I'm recommending usage of any of those (which is linked
> to us most of the time?) or fan of D-Bus (I'm not). I've just thought
> it might be less code to use it for autodetection of VM type, but
> apparently not (?) See their detect_vm_cpuid() with that vm_table[]
> and memcmp() seems to be a more elegant way of writing this.

Thanks for sharing - agreed that the vm_table approach they picked in
systemd's detect_vm_cpuid seems more elegant than the current
comparison mechanism.

I do think its reasonable for us to check this directly, since we're
already working with cpuid information anyway, and we also need the
TSC frequency data in the Hypervisor specific leafs (i.e. its not just
about getting the VM vendor name itself). For example, I don't think
HyperV provides TSC frequency in 0x40000010 - it was something VMware
added initially, that KVM subsequently added.

>
> BTW, -1 to fast_clock_source, +1 to clock_source or maybe
> explain_clock_source(?)

If the combined RDTSC/RDTSCP usage (as in v5) makes sense to people, I
think "clock_source" would probably make most sense - since we'd use
RDTSCP in all "slow" paths, not the system clock source.

On the other hand, if we rework this to only be relevant in the "fast"
code paths (i.e. use RDTSC for fast, but use the system clock source
always for slow) then a more narrow wording seems better.

> Also it would be cool if the patch would provide some way of reporting back
> what clock_source was really used in case of FAST_CLOCK_SOURCE_AUTO.
> Something like huge_pages_status or some elog(DEBUG).

Agreed, I think that would be useful.

Thanks for reviewing!

Thanks,
Lukas

-- 
Lukas Fittl