Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
От | Maciek Sakrejda |
---|---|
Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
Дата | |
Msg-id | CAOtHd0DaNYGpffTN+J-d2Bj+0a+vjCneoYTbTMog=1G1jZ1jBw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (Maciek Sakrejda <m.sakrejda@gmail.com>) |
Список | pgsql-hackers |
On Fri, Jul 15, 2022 at 11:21 AM Maciek Sakrejda <m.sakrejda@gmail.com> wrote: > On Fri, Jul 1, 2022 at 10:26 AM Andres Freund <andres@anarazel.de> wrote: > > On 2022-07-01 01:23:01 -0700, Lukas Fittl wrote: > >... > > > Known WIP problems with this patch version: > > > > > > * There appears to be a timing discrepancy I haven't yet worked out, where > > > the \timing data reported by psql doesn't match what EXPLAIN ANALYZE is > > > reporting. With Andres' earlier test case, I'm seeing a consistent ~700ms > > > higher for \timing than for the EXPLAIN ANALYZE time reported on the > > > server > > > side, only when rdtsc measurement is used -- its likely there is a problem > > > somewhere with how we perform the cycles to time conversion > > > > Could you explain a bit more what you're seeing? I just tested your patches > > and didn't see that here. > > I did not see this either, but I did see that the execution time > reported by \timing is (for this test case) consistently 0.5-1ms > *lower* than the Execution Time reported by EXPLAIN. I did not see > that on master. Is that expected? For what it's worth, I can no longer reproduce this. In fact, I went back to master-as-of-around-then and applied Lukas' v2 patches again, and I still can't reproduce that. I do remember it happening consistently across several executions, but now \timing consistently shows 0.5-1ms slower, as expected. This does not explain the different timing issue Lukas was seeing in his tests, but I think we can assume what I reported originally here is not an issue.
В списке pgsql-hackers по дате отправления: