Horton

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Lukas Fittl <lukas@fittl.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>, David Geier <geidav.pg@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, vignesh C <vignesh21@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, Maciek Sakrejda <m.sakrejda@gmail.com>, Tomas Vondra <tomas@vondra.me>
Date: 2025-07-29T02:30:11Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_test_timing: Also test RDTSC[P] timing, report time source, TSC frequency

  2. Allow retrieving x86 TSC frequency/flags from CPUID

  3. instrumentation: Standardize ticks to nanosecond conversion method

  4. instrumentation: Use Time-Stamp Counter on x86-64 to lower overhead

  5. Zero initialize uses of instr_time about to trigger compiler warnings

  6. instr_time: Represent time as an int64 on all platforms

  7. Add 250c8ee07ed to git-blame-ignore-revs

On Mon, Jul 28, 2025 at 03:38:20PM +0900, Michael Paquier wrote:
> On Sun, Jul 27, 2025 at 12:50:54PM -0700, Lukas Fittl wrote:
>> - Fix a typo (configure was incorrectly checking for "__get_cpuidex", vs
>> meson.build was doing it correctly)
> 
> It seems to me that this is an independent issue that had better be
> backpatched down to where this configure check has been introduced,
> no?

Please note that updates of ./configure should never be manual, these 
are done as follows:
- Update of ./autoconf.ac
- run of autoreconf -i or equivalent to update ./configure.  (I just
use the former, just my no-brainer to handle things.  Committers are
usually responsible for that, but it may matter to keep the CI happy.)

And I have noticed a second inconsistency with __cpuid(), both
introduced by 3dc2d62d0486 as far as I can see, so we have never
checked for these routines.  This is an independent issue for
something that should be backpatched, so I've spawned a new thread
(don't worry you have author credits):
https://www.postgresql.org/message-id/aIgwNYGVt5aRAqTJ@paquier.xyz
--
Michael