Hi, On 2023-01-20 07:43:00 +0100, David Geier wrote: > On 1/18/23 13:52, David Geier wrote: > > On 1/16/23 21:39, Pavel Stehule wrote: > > > > > > po 16. 1. 2023 v 21:34 odesílatel Tomas Vondra > > > <tomas.von...@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) > > > > > > +1 > > > > 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. > Thinking about this a little more made me realize that this will cause > different pg_regress output depending on the platform. So if we go this > route we would at least need an option for EXPLAIN ANALYZE to disable it. Or > rather have it disabled by default and allow for enabling it. Thoughts?
The elapsed time is already inherently unstable, so we shouldn't have any test output showing the time. But I doubt showing it in every explain is a good idea - we use instr_time in plenty of other places. Why show it in explain, but not in all those other places? Greetings, Andres Freund
