Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Hi,

On 2026-04-07 11:24:20 -0700, Lukas Fittl wrote:
> > I've pushed 0001, 0002, 0003.
>
> Yay! Thank you for pushing :)
>
> And thank you everyone on this thread for countless reviews, and to
> David for writing some essential parts of this earlier.

Seconded!

> > There's one minor documentation issue in 0004 that I wanted to look at before
> > pushing (and I need to switch to something else for a bit). The rephrasing
> > gets rid of
> >
> > - [...] , with the worst case somewhere between 32768 and
> > - 65535 nanoseconds. In the second block, we can see that typical loop
> > - time is 16 nanoseconds, and the readings appear to have full nanosecond
> > - precision.
> >
> > I don't mind loosing the first sentence, but the second one might be useful to
> > somebody?
>
> Hm, yeah, you're right. What if we word like this:
>
> <para>
> The example results below show system clock timing where 99.99% of loops
> took between 16 and 63 nanoseconds. In the second block, we can see that
> the typical loop time is 40 nanoseconds, and the readings appear to have
> full nanosecond precision. Following the system clock results, the
> <acronym>TSC</acronym> clock source results are shown. The
> <command>RDTSCP</command> instruction shows most loops completing in
> 20&ndash;30 nanoseconds, while the <command>RDTSC</command> instruction
> is the fastest with an average loop time of 20 nanoseconds. In this
> example the <acronym>TSC</acronym> clock source will be used by default,
> but can be disabled by setting <varname>timing_clock_source</varname> to
> <literal>system</literal>.
> </para>

Works.

Before pushing I vaccilated a bit about whether to replace the track_io_timing
reference in

+ On platforms that support the <acronym>TSC</acronym> clock source,
+ additional output sections are shown for the <command>RDTSCP</command>
+ instruction (used for general timing needs, such as
+ <varname>track_io_timing</varname>) and the <command>RDTSC</command>
+ instruction (used for <command>EXPLAIN ANALYZE</command>). At the end

given it's one of the more likely cases to be converted to the fast
timestamping. But in a decision I may live to regret, I deferred coming up
with a good way to phrase the difference between "per node timing" and
"overall query duration".

Pushed.

Yay!

Took only 6 years :)

Greetings,

Andres Freund