Message-ID: <67931b8a-27a6-4d68-ae42-2bea87b56569@proxel.se>
Date: Fri, 13 Feb 2026 17:47:16 +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>, Lukas Fittl <lukas@fittl.com>
Cc: Andres Freund <andres@anarazel.de>, David Geier <geidav.pg@gmail.com>,
 Jakub Wartak <jakub.wartak@enterprisedb.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: <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>
 <aY5Si7r2SMe4fRPc@alap3.anarazel.de>
 <CAP53PkxNJ2Y6G8PEpQn1zKa6ODE6k1-oP9DNqWjkTj=dC8_KiA@mail.gmail.com>
 <CAMT0RQQSLRFKGAccE+Ykm5gWbqR++HZ4kh_6Vrv3tNLA=WJFWg@mail.gmail.com>
From: Andreas Karlsson <andreas@proxel.se>
Content-Language: en-US
In-Reply-To: <CAMT0RQQSLRFKGAccE+Ykm5gWbqR++HZ4kh_6Vrv3tNLA=WJFWg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/67931b8a-27a6-4d68-ae42-2bea87b56569%40proxel.se>
Precedence: bulk

On 2/13/26 3:42 PM, Hannu Krosing wrote:
> I haven't looked at the code here yet, but when using plain rdtsc on
> modern CPUs one sees much more overhead from just the fact that the
> code is there than from calling the rdtsc instruction, and the
> overhead can vary by orders of magnitude based on how complex the work
> is that is timed.
> 
> I discovered this when I timed the (then-)new dead tid lookups in the
> Vacuum in Pg 17 and saw significantly larger overhead per lookup when
> the lookups themselves were slower, i.e. a case where the lookups were
> done in random order (inded was on  created on a column filled with
> random())
> 
> So while just a tight loop of N million rtdsc calls will give you the
> lower limit, it is likely not very representative of actual overhead.

Isn't the same issue still there if you call clock_gettime() but that it 
is just less noticeable due to the high cost of clock_gettime()?

Andreas