From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gettimeofday is at the end of its usefulness? |
Date: | 2016-06-08 11:41:01 |
Message-ID: | CAA-aLv7m=RU0vKm1myt_uRLYmTviqFcfWZCMPwbXdbKoX4YzYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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:
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-08 12:00:12 | Re: If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back? |
Previous Message | Tatsuo Ishii | 2016-06-08 10:43:56 | Re: If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back? |