Re: gettimeofday is at the end of its usefulness?
От | Thom Brown |
---|---|
Тема | Re: gettimeofday is at the end of its usefulness? |
Дата | |
Msg-id | CAA-aLv7m=RU0vKm1myt_uRLYmTviqFcfWZCMPwbXdbKoX4YzYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: gettimeofday is at the end of its usefulness? (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: gettimeofday is at the end of its usefulness?
|
Список | 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
В списке pgsql-hackers по дате отправления: