Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Lukas Fittl <lukas(at)fittl(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, David Geier <geidav(dot)pg(at)gmail(dot)com>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date: 2026-03-25 05:38:58
Message-ID: CANWCAZaPDVfO-f_Ejk_fJmSWU64ob8bK5uo9bUz_9pAuzgSVRg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 24, 2026 at 9:29 PM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
>
> Hi John,
>
> On Tue, Mar 24, 2026 at 3:59 AM John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
> > Looks good. The only thing that I would change is the single-letter
> > parameter/variable name "r". We could call it "reg" and it'd still be
> > pretty short. If you agree or have another suggestion, I can change
> > locally before pushing 0001 -- no need for a new patch set yet.
>
> Sure, I mainly felt that "exx" would be odd to keep, but "reg" sounds good.

Okay, pushed that way. I also took the liberty of moving a couple
comment changes in 0005 to here. My hope is that will reduce merge
conflicts with the AVX checksums patch, since that one also
invalidates one of those comments and it's not clear which will be
committed first.

--
John Naylor
Amazon Web Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-03-25 05:54:07 Re: Reduce log level of some logical decoding messages to DEBUG1
Previous Message Lukas Fittl 2026-03-25 05:34:29 Re: Stack-based tracking of per-node WAL/buffer usage