Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

On 22.10.2025 15:32, Andres Freund wrote:
> Hi,
>
> On 2025-09-01 12:36:24 +0200, David Geier wrote:
>>> Open questions I have:
>>> - Could we rely on checking whether the TSC timesource is invariant (via
>>> CPUID), instead of relying on Linux choosing it as a clocksource?
>>
>> Why do you want to do that? Are you concerned that Linux might pick a
>> different clock source even though invariant TSC is available?
>
> Not sure about Lukas, but I'm slightly concerned about making this a linux
> specific mechanism unnecessarily.
>

Considering [1], Lukas seems to share my concerns that building or own
has the risk of missing cases.

>
>> We could code our own check but looking at the Linux kernel code, this
>> is a bit more involved if we want to do it completely right. They check
>> e.g. if the TSC is also synchronized across different CPUs, which is not
>> the case if they're on different chassis (see unsynchronized_tsc() ->
>> apic_is_clustered_box()).
>
> I think Linux has higher fidelity requirements than our instrumentation usage
> - with linux an inaccurate clock would lead to broken timers, wrong wall clock
> etc, whereas for us it's just a skewed instrumentation result.

That's true. As long as we use the RDTSCP basd code only in places where
it doesn't affect "correctness" it's not the end of the world if they're
skewed.

I'll give it a try to code our own detection mechanism and will share
findings here. Then we can make a call based on the learnings.

--
David Geier

[1]
https://www.postgresql.org/message-id/CAP53Pky-BN0Ui%2BA9no3TsU%3DGoMTFpxYSWYtp_LVaDH%3Dy69BxNg%40mail.gmail.com