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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?