Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Поиск
Список
Период
Сортировка
От Lukas Fittl
Тема Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Дата
Msg-id CAP53PkwtWtY-hkSwV7E6g_n657RnFcK0asSp0foSk5Qz_CCJXQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?  (David Geier <geidav.pg@gmail.com>)
Ответы Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?  (David Geier <geidav.pg@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
Hi David,

Thanks for continuing to work on this patch, and my apologies for silence on the patch.

Its been hard to make time, and especially so because I typically develop on an ARM-based macOS system where I can't test this directly - hence my tests with virtualized EC2 instances, where I ran into the timing oddities.

On Mon, Jan 2, 2023 at 5:28 AM David Geier <geidav.pg@gmail.com> wrote:
The INSTR_TIME_GET_MICROSEC() returns a uint64 while the other variants
return double. This seems error prone. What about renaming the function
or also have the function return a double and cast where necessary at
the call site?

Minor note, but in my understanding using a uint64 (where we can) is faster for any simple arithmetic we do with the values.
 
If no one objects I would also re-register this patch in the commit fest.

+1, and feel free to carry this patch forward - I'll try to make an effort to review my earlier testing issues again, as well as your later improvements to the patch.

Also, FYI, I just posted an alternate idea for speeding up EXPLAIN ANALYZE with timing over in [0], using a sampling-based approach to reduce the timing overhead.


Thanks,
Lukas

--
Lukas Fittl

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: New strategies for freezing, advancing relfrozenxid early
Следующее
От: Dag Lem
Дата:
Сообщение: Re: daitch_mokotoff module