Message-ID: <c84b9cd8-1e1d-4d1c-991b-2063331f1385@gmail.com>
Date: Wed, 3 Dec 2025 12:03:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
To: Robert Haas <robertmhaas@gmail.com>, Lukas Fittl <lukas@fittl.com>
Cc: 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>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: 
 <CA+TgmobAbCwvZMnMPJA9OBzHYbEsGCwCmOHPr0wRVxjkEo7RDQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c84b9cd8-1e1d-4d1c-991b-2063331f1385%40gmail.com>
Precedence: bulk

On 19.11.2025 20:36, Robert Haas wrote:
> On Wed, Nov 19, 2025 at 11:55 AM Lukas Fittl <lukas@fittl.com> wrote:
>> Overall, I'm still thinking a GUC might be the way to go, but I don't think anyone else was enthusiastic about that idea :)
> 
> Reliable feature auto-detection is the best option, but if that's not
> possible, I think the choices are add a GUC or give up on the project
> altogether. Using a GUC to deal with platform dependencies is a pretty
> reasonable concept -- see, e.g. dynamic_shared_memory_type or
> huge_pages or io_method. If we can't autodetect it reliably and we
> aren't willing to add a GUC, we're basically saying there's not enough
> value here to justify adding a configuration parameter. That's often a
> totally reasonable conclusion -- it can easily happen that the
> benefits of a platform-specific optimization are too small to make it
> worth configuring. But I would have thought that in this case the
> benefits might be quite large.

I'm also in favor of adding a GUC. Even if we could 100% reliably detect
if using TSC is giving correct results, it could be that it's slow in
some virtualized environment and hence the user wants to disable it.

I'm wondering how to best do a GUC for something that is potentially
unavailable on the system. In that case the GUC would be superfluous.
Maybe a boolean "enable_try_fast_clocksource" GUC or a "clocksource"
enum GUC which can be "default" and "try_rdtsc", where we only include
the "try_rdtsc" enum value on x86 systems?

Any other ideas?

--
David Geier