pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: David Geier <geidav.pg@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Lukas Fittl <lukas@fittl.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Ibrar Ahmed <ibrar.ahmad@gmail.com>
Cc: Maciek Sakrejda <m.sakrejda@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date: Wed, 19 Nov 2025 08:25:58 +0100
Message-ID: <57845c37-85e8-4d0e-9456-76833e089c5d@gmail.com> (raw)
In-Reply-To: <p3ygm5nnefekhj6sfoanzwqygcz3edag7shblkidq47l3ys3r2@v2twclclhlwm>
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>

On 22.10.2025 15:32, Andres Freund wrote:
> Hi,
> 
> On 2025-09-01 12:36:24 +0200, David Geier wrote:
>>> Open questions I have:
>>> - Could we rely on checking whether the TSC timesource is invariant (via
>>> CPUID), instead of relying on Linux choosing it as a clocksource?
>>
>> Why do you want to do that? Are you concerned that Linux might pick a
>> different clock source even though invariant TSC is available?
> 
> Not sure about Lukas, but I'm slightly concerned about making this a linux
> specific mechanism unnecessarily.
> 

Considering [1], Lukas seems to share my concerns that building or own
has the risk of missing cases.


> 
>> We could code our own check but looking at the Linux kernel code, this
>> is a bit more involved if we want to do it completely right. They check
>> e.g. if the TSC is also synchronized across different CPUs, which is not
>> the case if they're on different chassis (see unsynchronized_tsc() ->
>> apic_is_clustered_box()).
> 
> I think Linux has higher fidelity requirements than our instrumentation usage
> - with linux an inaccurate clock would lead to broken timers, wrong wall clock
> etc, whereas for us it's just a skewed instrumentation result.

That's true. As long as we use the RDTSCP basd code only in places where
it doesn't affect "correctness" it's not the end of the world if they're
skewed.

I'll give it a try to code our own detection mechanism and will share
findings here. Then we can make a call based on the learnings.

--
David Geier

[1]
https://www.postgresql.org/message-id/CAP53Pky-BN0Ui%2BA9no3TsU%3DGoMTFpxYSWYtp_LVaDH%3Dy69BxNg%40ma...





view thread (172+ messages)  latest in thread

Message-ID: <57845c37-85e8-4d0e-9456-76833e089c5d@gmail.com>
Permalink:  ../57845c37-85e8-4d0e-9456-76833e089c5d@gmail.com/
Also on:    postgresql.org/message-id/57845c37-85e8-4d0e-9456-76833e089c5d@gmail.com

 · 

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: pgsql-hackers@postgresql.org
  Cc: geidav.pg@gmail.com, andres@anarazel.de, lukas@fittl.com, pavel.stehule@gmail.com, tomas.vondra@enterprisedb.com, vignesh21@gmail.com, michael@paquier.xyz, ibrar.ahmad@gmail.com, m.sakrejda@gmail.com
  Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
  In-Reply-To: <57845c37-85e8-4d0e-9456-76833e089c5d@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox