Re: gettimeofday is at the end of its usefulness?
Thom Brown <thom@linux.com>
From: Thom Brown <thom@linux.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-08T11:41:01Z
Lists: pgsql-hackers
On 15 May 2014 at 19:56, Bruce Momjian <bruce@momjian.us> wrote: > On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote: > > A recent question from Tim Kane prompted me to measure the overhead > > costs of EXPLAIN ANALYZE, which I'd not checked in awhile. Things > > are far worse than I thought. On my current server (by no means > > lavish hardware: Xeon E5-2609 @2.40GHz) a simple seqscan can run > > at something like 110 nsec per row: > > I assume you ran pg_test_timing too: > > Testing timing overhead for 3 seconds. > Per loop time including overhead: 41.70 nsec > Histogram of timing durations: > < usec % of total count > 1 95.83035 68935459 > 2 4.16923 2999133 > 4 0.00037 268 > 8 0.00004 31 > 16 0.00000 1 > 32 0.00000 1 > > My overhead of 41.70 nsec matches yours. > Did this idea die, or is it still worth considering? Thom
Commits
-
Use clock_gettime(), if available, in instr_time measurements.
- 1d63f7d2d180 10.0 landed