Message-ID: <7717ba64-9283-49ec-aa3f-34c6de848b93@gmail.com>
Date: Fri, 5 Dec 2025 08:46:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
To: Hannu Krosing <hannuk@google.com>, Robert Haas <robertmhaas@gmail.com>
Cc: Lukas Fittl <lukas@fittl.com>, Andres Freund <andres@anarazel.de>,
 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>
References: <b1aff6c5-53a8-65af-2d3e-71ff2c96b0da@gmail.com>
 <20230123174158.rhmrbmjp6ycak64r@awork3.anarazel.de>
 <a9b2649b-36a0-2e69-e1fd-779e5faf4b7d@gmail.com>
 <20230207181218.47irz3of34qsww5l@awork3.anarazel.de>
 <989acbcf-e950-7911-c2e2-fe7aa7d15108@gmail.com>
 <eba40e62-c1d0-810b-55c2-c037a2dc578c@gmail.com>
 <198ef658-a5b7-9862-2017-faf85d59e3a8@gmail.com>
 <20240601185200.riqzbabh5azna2fr@alap3.anarazel.de>
 <CAP53PkzO2KpscD-tgFW_V-4WS+vkniH4-B00eM-e0bsBF-xUxg@mail.gmail.com>
 <bf04c66b-f062-4a7a-bf2f-7c1d7e262ad6@gmail.com>
 <p3ygm5nnefekhj6sfoanzwqygcz3edag7shblkidq47l3ys3r2@v2twclclhlwm>
 <57845c37-85e8-4d0e-9456-76833e089c5d@gmail.com>
 <CAP53PkzLstzEHfZkXb_G7gpqDOWQa9bpG69HDmTSEA0ovRyiXw@mail.gmail.com>
 <CA+TgmobAbCwvZMnMPJA9OBzHYbEsGCwCmOHPr0wRVxjkEo7RDQ@mail.gmail.com>
 <c84b9cd8-1e1d-4d1c-991b-2063331f1385@gmail.com>
 <CA+TgmoZMpaXoW8X8JwvKBXUZXiNbF+tOEpPzY_ocFthPNWo0Ug@mail.gmail.com>
 <CAMT0RQSvvWi22_D1q9jTgiTBC5h8PDrzAwF4GTW4_-jqFGbouQ@mail.gmail.com>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: 
 <CAMT0RQSvvWi22_D1q9jTgiTBC5h8PDrzAwF4GTW4_-jqFGbouQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/7717ba64-9283-49ec-aa3f-34c6de848b93%40gmail.com>
Precedence: bulk

On 04.12.2025 22:21, Hannu Krosing wrote:
> I have not looked at this patch series yet, but when I played around
> with using rdtsc (or actually some gcc/clang construct that compiled
> to rctsc on c86 and into time register reads on Arm and risc-v) then
> any extra step around it had noticeable overhead. I am not sure
> putting some if or function call around rdtsc call is a good idea.

We have that already. INSTR_TIME_SET_CURRENT_FAST() is currently
implemented as:

static inline instr_time
pg_get_ticks_fast(void)
{
#if defined(__x86_64__) && defined(__linux__)
	if (has_rdtsc)
	{
		instr_time	now;

		now.ticks = __rdtsc();
		return now;
	}
#endif

	return pg_clock_gettime();
}

Based on Robert's suggestion I wanted to add a "fast_clock_source" enum
GUC which can have the following values "auto", "rdtsc", "try_rdtsc" and
"off". With that, at least no additional checks are needed and
performance will remain as previously benchmarked in this thread.

Beyond that, the condition will always evaluate to the same result, so
there won't be branch mispredictions. Doing completely without any check
is impossible, except if we were to JIT compile InstrStartNode() and
InstrStopNode(). But that's a much bigger project.

I'll still add unlikely() around the if (has_rdtsc).

Any input regarding the proposed GUC is welcome.

--
David Geier