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
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? |