Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

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.

On Wed, Dec 3, 2025 at 3:15 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Dec 3, 2025 at 6:03 AM David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
> > 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?
>
> huge_pages=on/off/try is one possible precedent. Perhaps for this
> case, we might do something like
> clock_source=auto/this/that/the_other_thing might be better. If you
> set it to any value other than "auto", the named source must be
> available, or startup fails. If you set it to auto, it picks what it
> believes to be the best option available, and there is some other
> read-only GUC (akin to huge_page_status) that tells you what it
> picked.
>
> I'm open to other suggestions as to how this should work, but (1) all
> of the existing enable_* GUCs are planner GUCs, and (2) I suspect it's
> short-sighted to plan for only "fast" and "not fast".
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>
>