Feedback-ID: id4a34324:Fastmail
Date: Thu, 12 Feb 2026 19:41:22 -0500
From: Andres Freund <andres@anarazel.de>
To: Lukas Fittl <lukas@fittl.com>
Cc: David Geier <geidav.pg@gmail.com>, 
	Jakub Wartak <jakub.wartak@enterprisedb.com>, Hannu Krosing <hannuk@google.com>, 
	Robert Haas <robertmhaas@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, 
	vignesh C <vignesh21@gmail.com>, Michael Paquier <michael@paquier.xyz>, 
	Ibrar Ahmed <ibrar.ahmad@gmail.com>, Maciek Sakrejda <m.sakrejda@gmail.com>, 
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Message-ID: <aY5Si7r2SMe4fRPc@alap3.anarazel.de>
References: <CA+TgmoZMpaXoW8X8JwvKBXUZXiNbF+tOEpPzY_ocFthPNWo0Ug@mail.gmail.com>
 <CAMT0RQSvvWi22_D1q9jTgiTBC5h8PDrzAwF4GTW4_-jqFGbouQ@mail.gmail.com>
 <7717ba64-9283-49ec-aa3f-34c6de848b93@gmail.com>
 <3bdce15d-25ec-4c49-9906-818803462897@gmail.com>
 <CAP53PkyooCeR8YV0BUD_xC7oTZESHz8OdA=tP7pBRHFVQ9xtKg@mail.gmail.com>
 <CAP53PkxaDpPCbXeA=OpmY4DUxBVHzgivXzpA62_tRE62xfc9nA@mail.gmail.com>
 <CAKZiRmzF50+drGgm6F-K1dQnuT=Khob0Q_dfZdv0-1iq4TVa4Q@mail.gmail.com>
 <vbfdgjxn4rqwbnznks4zstx7t34dcrhubbmse775ou4nmcjqzi@4rugaq7sftac>
 <1e0462f0-8274-4d57-aa39-9b6ebeb954da@gmail.com>
 <CAP53PkxAtD_ArzxaXPMgAKTfT5Da34o-oN9JY32UbhFS3U=-6A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAP53PkxAtD_ArzxaXPMgAKTfT5Da34o-oN9JY32UbhFS3U=-6A@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aY5Si7r2SMe4fRPc%40alap3.anarazel.de>
Precedence: bulk

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