public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Lukas Fittl <[email protected]>
Cc: David Geier <[email protected]>
Cc: Jakub Wartak <[email protected]>
Cc: Hannu Krosing <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: vignesh C <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Ibrar Ahmed <[email protected]>
Cc: Maciek Sakrejda <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date: Thu, 12 Feb 2026 19:41:22 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAP53PkxAtD_ArzxaXPMgAKTfT5Da34o-oN9JY32UbhFS3U=-6A@mail.gmail.com>
References: <CA+TgmoZMpaXoW8X8JwvKBXUZXiNbF+tOEpPzY_ocFthPNWo0Ug@mail.gmail.com>
<CAMT0RQSvvWi22_D1q9jTgiTBC5h8PDrzAwF4GTW4_-jqFGbouQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAP53PkyooCeR8YV0BUD_xC7oTZESHz8OdA=tP7pBRHFVQ9xtKg@mail.gmail.com>
<CAP53PkxaDpPCbXeA=OpmY4DUxBVHzgivXzpA62_tRE62xfc9nA@mail.gmail.com>
<CAKZiRmzF50+drGgm6F-K1dQnuT=Khob0Q_dfZdv0-1iq4TVa4Q@mail.gmail.com>
<vbfdgjxn4rqwbnznks4zstx7t34dcrhubbmse775ou4nmcjqzi@4rugaq7sftac>
<[email protected]>
<CAP53PkxAtD_ArzxaXPMgAKTfT5Da34o-oN9JY32UbhFS3U=-6A@mail.gmail.com>
Hi,
On 2026-02-12 08:05:27 -0800, Lukas Fittl wrote:
> On master (88327092ff0), I'm getting 23.54 ns from pg_test_timing - vs
> with 0002 applied, this slows to 25.74 ns. I've tried to see if the
> "unlikely(..)" we added in pg_ticks_to_ns is the problem (since in the
> clock_gettime() case we'd always be running into that branch due to
> the size of the nanoseconds value), but no luck - I think the extra
> multiplication/division itself is the problem.
>
> Any ideas how we could do this differently?
The problem looks to be that you're going to take the slowpath when using
clock_gettime(), unless you booted within the last three days, because
pg_test_timing() is doing
INSTR_TIME_SET_CURRENT(temp);
cur = INSTR_TIME_GET_NANOSEC(temp);
Which will require reducing time-since-boot in nanoseconds (with
CLOCK_MONOTONIC) via pg_ticks_to_ns() overflow logic, as the way
max_ticks_no_overflow is set in 0001, it'll overflow after a few days of
runtime.
This can largely be addressed by keeping prev and cur in the instr_time
domain and only converting the difference to nanoseconds.
I wonder if pg_test_timing should have a small loop with a fixed count to
determine the timing without all the overhead the existing loop has...
Greetings,
Andres Freund
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox