Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
В списке pgsql-hackers по дате отправления:
| От | David Geier |
|---|---|
| Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Дата | |
| Msg-id | 1e0462f0-8274-4d57-aa39-9b6ebeb954da@gmail.com обсуждение исходный текст |
| Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
On 03.02.2026 18:44, Andres Freund wrote: > Yea, I doubt this is the right path... Particularly because I really think we > ought to eventually use this not just on linux but other OSs as well. +1 >> BTW, -1 to fast_clock_source, +1 to clock_source or maybe >> explain_clock_source(?) > > 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? Makes sense. clock_source_timing works for me, or maybe easier to read would be timing_clock_source. But doesn't matter much. -- David Geier
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера