Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
David Geier <geidav.pg@gmail.com>
From: David Geier <geidav.pg@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>,
Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: vignesh C <vignesh21@gmail.com>, Lukas Fittl <lukas@fittl.com>,
Michael Paquier <michael@paquier.xyz>, Ibrar Ahmed <ibrar.ahmad@gmail.com>,
Maciek Sakrejda <m.sakrejda@gmail.com>, Andres Freund <andres@anarazel.de>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-01-20T06:43:00Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_test_timing: Also test RDTSC[P] timing, report time source, TSC frequency
- 16fca4825483 19 (unreleased) landed
-
Allow retrieving x86 TSC frequency/flags from CPUID
- bcb2cf41f964 19 (unreleased) landed
-
instrumentation: Standardize ticks to nanosecond conversion method
- 0022622c93d9 19 (unreleased) landed
-
instrumentation: Use Time-Stamp Counter on x86-64 to lower overhead
- 294520c44487 19 (unreleased) landed
-
Zero initialize uses of instr_time about to trigger compiler warnings
- 25b2aba0c3a5 16.0 landed
-
instr_time: Represent time as an int64 on all platforms
- 03023a2664f8 16.0 landed
-
Add 250c8ee07ed to git-blame-ignore-revs
- ff23b592ad66 16.0 cited
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.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) >> >> +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? -- David Geier (ServiceNow)