Re: gettimeofday is at the end of its usefulness?
От | Tom Lane |
---|---|
Тема | Re: gettimeofday is at the end of its usefulness? |
Дата | |
Msg-id | 20237.1465397783@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: gettimeofday is at the end of its usefulness? (Thom Brown <thom@linux.com>) |
Ответы |
Re: gettimeofday is at the end of its usefulness?
Re: gettimeofday is at the end of its usefulness? |
Список | pgsql-hackers |
Thom Brown <thom@linux.com> writes: > 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: > 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
В списке pgsql-hackers по дате отправления: