Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Дата
Msg-id xzh4cohdstkdquvuc62ilvolpp4kxuvnfqt5l5hvgdgvifdfdz@kwfwx65q2ka6
обсуждение исходный текст
Ответ на Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Список pgsql-hackers
Hi,

On 2026-02-03 12:44:21 -0500, Andres Freund wrote:
> Hm. I think it'd make sense to use eventually use this clock source for other
> timing tasks too, not just explain.  E.g. pg_stat_statements could benefit
> quite a bit from reducing the timing overhead.
> 
> Whereas it'll not make sense for anything that needs wall clock times - which
> imo makes a "clock_source" GUC misnamed.  Maybe "clock_source_timing" or such?

I forgot another important one we really should use the fast timing for:
track_io_timing/track_wal_io_timing. The overhead of IO timing can be
noticeable on busy systems and it's hard to believe that the inaccuracy
matters.  This is probably particularly relevant when measuring IO intensive
workloads where the data resides in the kernel page cache, but doesn't fit
into s_b.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления: