Message-ID: <1e0462f0-8274-4d57-aa39-9b6ebeb954da@gmail.com>
Date: Wed, 4 Feb 2026 11:09:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
To: Andres Freund <andres@anarazel.de>,
 Jakub Wartak <jakub.wartak@enterprisedb.com>
Cc: Lukas Fittl <lukas@fittl.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>
References: 
 <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>
 <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>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: <vbfdgjxn4rqwbnznks4zstx7t34dcrhubbmse775ou4nmcjqzi@4rugaq7sftac>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/1e0462f0-8274-4d57-aa39-9b6ebeb954da%40gmail.com>
Precedence: bulk

On 03.02.2026 18:44, Andres Freund wrote:
> Yea, I doubt this is the right path... Particularly because I really think we
> ought to eventually use this not just on linux but other OSs as well.

+1

>> BTW, -1 to fast_clock_source, +1 to clock_source or maybe
>> explain_clock_source(?)
> 
> Hm. I think it'd make sense to use eventually use this clock source for other
> timing tasks too, not just explain.  E.g. pg_stat_statements could benefit
> quite a bit from reducing the timing overhead.
> 
> Whereas it'll not make sense for anything that needs wall clock times - which
> imo makes a "clock_source" GUC misnamed.  Maybe "clock_source_timing" or such?

Makes sense. clock_source_timing works for me, or maybe easier to read
would be timing_clock_source. But doesn't matter much.

--
David Geier