| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Date: | 2025-12-03 14:15:00 |
| Message-ID: | CA+TgmoZMpaXoW8X8JwvKBXUZXiNbF+tOEpPzY_ocFthPNWo0Ug@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Yurichev | 2025-12-03 14:19:37 | Re: IPC/MultixactCreation on the Standby server |
| Previous Message | Greg Burd | 2025-12-03 14:11:03 | Re: Refactor how we form HeapTuples for CatalogTuple(Insert|Update) |