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 по дате отправления: