Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
От | David Geier |
---|---|
Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
Дата | |
Msg-id | b929cab3-c07f-6d89-5a5f-35d5e5e9ba8a@gmail.com обсуждение исходный текст |
Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
|
Список | pgsql-hackers |
On 1/16/23 21:39, Pavel Stehule wrote: > > po 16. 1. 2023 v 21:34 odesílatel Tomas Vondra > <tomas.vondra@enterprisedb.com> napsal: > > Hi, > > there's minor bitrot in the Mkvcbuild.pm change, making cfbot unhappy. > > As for the patch, I don't have much comments. I'm wondering if it'd be > useful to indicate which timing source was actually used for EXPLAIN > ANALYZE, say something like: > > Planning time: 0.197 ms > Execution time: 0.225 ms > Timing source: clock_gettime (or tsc) > > There has been a proposal to expose this as a GUC (or perhaps as > explain > option), to allow users to pick what timing source to use. I > wouldn't go > that far - AFAICS is this is meant to be universally better when > available. But knowing which source was used seems useful. > > > +1 Thanks for looking at the patch. I'll fix the merge conflict. I like the idea of exposing the timing source in the EXPLAIN ANALYZE output. It's a good tradeoff between inspectability and effort, given that RDTSC should always be better to use. If there are no objections I go this way. -- David Geier (ServiceNow)
В списке pgsql-hackers по дате отправления: