Re: gettimeofday is at the end of its usefulness? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: gettimeofday is at the end of its usefulness?
Date
Msg-id 20237.1465397783@sss.pgh.pa.us
Whole thread Raw
In response to Re: gettimeofday is at the end of its usefulness?  (Thom Brown <thom@linux.com>)
Responses Re: gettimeofday is at the end of its usefulness?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: gettimeofday is at the end of its usefulness?  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
Thom Brown <thom@linux.com> writes:
> 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:

> Did this idea die, or is it still worth considering?

We still have a problem, for sure.  I'm not sure that there was any
consensus on what to do about it.  Using clock_gettime(CLOCK_REALTIME)
if available would be a straightforward change that should ameliorate
gettimeofday()'s 1-usec-precision-limit problem; but it doesn't do
anything to fix the excessive-overhead problem.  The ideas about the
latter were all over the map, and none of them looked easy.

If you're feeling motivated to work on this area, feel free.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Rename max_parallel_degree?
Next
From: Amit Kapila
Date:
Subject: Re: Reviewing freeze map code