Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Hi Zsolt,

On Mon, Apr 6, 2026 at 4:36 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> +uint64 max_ticks_no_overflow = 0;
>
> Could this be int64? It is based on PG_INT64_MAX, and it's only
> practical use is with a cast to int64.

Its intentionally uint64, per this comment above it:

* Note we utilize unsigned integers even though ticks are stored as a signed
* value to encourage compilers to generate better assembly, since we can be
* sure these values are not negative.

In my earlier Compiler Explorer tests that did actually make a
difference for the generated assembly.

>
> > This allows the direct use of the Time-Stamp Counter (TSC) value retrieved
> > from the CPU using RDTSC/RDTSC instructions,
>
> Typo in commit message for 0003: RDTSC/RDTSC
>
> + else
> + printf(_("TSC clock source is not usable. Likely unable to determine
> TSC frequency. are you running in an unsupported virtualized
> environment?.\n"));
> +}
>
> Typo: are, ?.

Agreed those are typos. Since I know Andres is actively taking a look
at things right now I'll hold off on posting a new version for this,
but thanks for noting.

>
> -/* TSC specific logic */
> +/* Hardware clock specific logic (x86 TSC / AArch64 CNTVCT) */
>
> Shouldn't this ARM patch also update the documentation?

Yes, it should, but there are other open items for the ARM patch
(mainly the detection of different CPU core types causing different
CNTVCT frequencies needs to be OS agnostic), so the ARM patch is not
targeted for 19. Its just in this patch set to illustrate how we can
expand coverage for it later.

Thanks,
Lukas

--
Lukas Fittl