Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? - Mailing list pgsql-hackers

Hi Haibo,

On Sat, Apr 11, 2026 at 11:04 PM Haibo Yan <tristan.yim@gmail.com> wrote:
>
> Thanks for the patch. I may be missing something, but I wonder if the new debug path can still end up calling
pg_tsc_calibrate_frequency()after tsc_detect_frequency() already bailed out with no rdtscp or not invariant. 
> If so, it seems the diagnostics path is no longer following the same gate as the normal TSC-usability path, and could
stillexecute pg_rdtscp() while only trying to print debug info. 
> Maybe I am overlooking a guard somewhere, but I think it would be safer either to use the same prerequisites here, or
keepthis helper purely passive. 

Yes, that's a good point. I don't think the TSC not being invariant
would be a problem on its own, but the RDTSCP instruction not being
available would presumably make the frequency function fail.

I think the easiest way to approach that is to only run the
calibration function in the debug path when we have a frequency, but
it wasn't determined through calibration. Per earlier note from Andres
running calibration in those cases is intentional to help us compare
CPUID data with what we got from calibration.

Attached v28, which also adds the exit(1) mentioned earlier.

FWIW, for archive's sake, drongo is green again now, thanks to commit
7fc36c5db550 (Avoid CPUID 0x15/0x16 for Hypervisor TSC frequency).

Thanks,
Lukas

--
Lukas Fittl