Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
| От | Robert Haas |
|---|---|
| Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Дата | |
| Msg-id | CA+TgmoZMpaXoW8X8JwvKBXUZXiNbF+tOEpPzY_ocFthPNWo0Ug@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (David Geier <geidav.pg@gmail.com>) |
| Список | pgsql-hackers |
On Wed, Dec 3, 2025 at 6:03 AM David Geier <geidav.pg@gmail.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
В списке pgsql-hackers по дате отправления: