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

From John Naylor
Subject Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date
Msg-id CANWCAZYqZSU7TcVfnTEXHSSjGmBBPBsDEZ9aO+O3b3kfpEB4pw@mail.gmail.com
Whole thread
In response to Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?  (Lukas Fittl <lukas@fittl.com>)
List pgsql-hackers
On Tue, Apr 7, 2026 at 10:42 AM Lukas Fittl <lukas@fittl.com> wrote:
>
> On Mon, Apr 6, 2026 at 5:40 PM Andres Freund <andres@anarazel.de> wrote:

> > I wonder if the cpuid tests should be a bit further abstracted into
> > pg_cpu_x86.c.
> >
> > E.g. instead of tsc_detect_frequency() checking for PG_RDTSCP,
> > PG_TSC_INVARIANT, PG_TSC_ADJUST we could have
> >
> > PG_TSC_AVAILABLE /* RDTSCP & INVARIANT */
> > PG_TSC_KNOWN_RELIABLE /* PG_TSC_AVAILABLE && PG_TSC_ADJUST */
> > PG_TSC_FREQUENCY_KNOWN /* x86_tsc_frequency_khz works */
> >
> > and always run all of that during set_x86_features().
>
> I think that could work, but I kept the flags in features closer to
> being direct mappings to CPUID bits since that seemed to be intent of
> how John designed the facility originally.
>
> John, do you have thoughts on this? (I've not changed it for now)

The intent is as how you described, but it's not because that way was
the best of all possible ways, more that it seemed to fit well
underneath the existing runtime checks. It's also already not quite a
direct mapping, since if OSXSAVE is not available, we don't bother
checking for/setting AVX at all.

--
John Naylor
Amazon Web Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Peter Smith
Date:
Subject: Re: Redundant/mis-use of _(x) gettext macro?