Re: gettimeofday is at the end of its usefulness?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: gettimeofday is at the end of its usefulness?
Date: 2016-06-08 14:56:23
Message-ID: 20237.1465397783@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thom Brown <thom(at)linux(dot)com> writes:
> On 15 May 2014 at 19:56, Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-06-08 16:01:39 Re: Reviewing freeze map code
Previous Message Robert Haas 2016-06-08 14:47:43 Re: Rename max_parallel_degree?