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