Re: [HACKERS] gettimeofday is at the end of its usefulness?

Florian Weimer writes: > glibc has some test cases which fail because clock_gettime gives > inconsistent results. This has been fixed in current kernels, but I > don't know if everyone uses them. hmm, for which clock IDs? regards, tom lane -- Sent

Re: [HACKERS] gettimeofday is at the end of its usefulness?

* Tom Lane: > Florian Weimer writes: >> * Tom Lane: >>> On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(), >>> clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME) >>> all take about 40ns. Of course gettimeofday() only has 1us resolution, >>> but the

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Fri, Dec 30, 2016 at 1:02 PM, Tom Lane wrote: > Haribabu Kommi writes: > > Attached a patch that replaces most of the getimeofday function calls, > > except timeofday(user callable) and GetCurrentTimestamp functions. > > I looked at this for

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Haribabu Kommi writes: > Attached a patch that replaces most of the getimeofday function calls, > except timeofday(user callable) and GetCurrentTimestamp functions. I looked at this for awhile and could not convince myself that it's a good idea. Trying to do

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Thomas Munro writes: > On Tue, Dec 27, 2016 at 10:34 AM, Tom Lane wrote: >> However, it seems that these impressive results date back only to >> June 2012, cf >> https://github.com/freebsd/freebsd/commit/13a9f42818f6b89a72b3e40923be809b490400d8

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Tue, Dec 27, 2016 at 10:34 AM, Tom Lane wrote: > I also tried FreeBSD 11.0 on another Mac (2.3GHz x86_64), > and found that gettimeofday as well as basically all their > clock_gettime variants run in 27 to 28 ns; and clock_gettime > reliably delivers full precision, except

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Florian Weimer writes: > * Tom Lane: >> On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(), >> clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME) >> all take about 40ns. Of course gettimeofday() only has 1us resolution, >> but the other two have

Re: [HACKERS] gettimeofday is at the end of its usefulness?

* Tom Lane: > On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(), > clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME) > all take about 40ns. Of course gettimeofday() only has 1us resolution, > but the other two have perhaps 10ns resolution (I get no duplicate > readings

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Andres Freund writes: > On 2016-12-27 01:35:05 +, Greg Stark wrote: >> On Dec 26, 2016 10:35 PM, "Tom Lane" wrote: >>> So it seems like the configure support we'd need is to detect >>> whether clock_gettime is available (note on Linux there's also >>>

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On 2016-12-27 01:35:05 +, Greg Stark wrote: > On Dec 26, 2016 10:35 PM, "Tom Lane" wrote: > > > So it seems like the configure support we'd need is to detect > whether clock_gettime is available (note on Linux there's also > a library requirement, -lrt), and we would

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Dec 26, 2016 10:35 PM, "Tom Lane" wrote: So it seems like the configure support we'd need is to detect whether clock_gettime is available (note on Linux there's also a library requirement, -lrt), and we would also need a way to provide a platform-specific choice of

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Haribabu Kommi writes: > Attached a patch that replaces most of the getimeofday function calls, > except timeofday(user callable) and GetCurrentTimestamp functions. > Didn't add any configure checks in case if the clock_gettime function is > not available, the fallback

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Thu, Aug 25, 2016 at 3:12 PM, Haribabu Kommi wrote: > On Thu, Jun 9, 2016 at 12:56 AM, Tom Lane wrote: > > Thom Brown writes: > >> On 15 May 2014 at 19:56, Bruce Momjian wrote: > >>> On Tue, May 13, 2014 at

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Thu, Jun 9, 2016 at 12:56 AM, Tom Lane wrote: > Thom Brown writes: >> On 15 May 2014 at 19:56, Bruce Momjian wrote: >>> On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote: A recent question from Tim Kane prompted me to measure

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On 2016-07-07 14:43:31 -0400, Robert Haas wrote: > On Tue, Jun 14, 2016 at 4:27 PM, Jim Nasby wrote: > > Semi-related: someone (Robert I think) recently mentioned investigating > > "vectorized" executor nodes, where multiple tuples would be processed in one > > shot. If

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Tue, Jun 14, 2016 at 4:27 PM, Jim Nasby wrote: > Semi-related: someone (Robert I think) recently mentioned investigating > "vectorized" executor nodes, where multiple tuples would be processed in one > shot. If we had that presumably the explain penalty would be a

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On 6/8/16 9:56 AM, Tom Lane wrote: Thom Brown writes: On 15 May 2014 at 19:56, Bruce Momjian 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

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Thom Brown writes: > On 15 May 2014 at 19:56, Bruce Momjian 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.

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On 15 May 2014 at 19:56, Bruce Momjian 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

Re: [HACKERS] gettimeofday is at the end of its usefulness?

I posted this on this mailing list before at Jane Street we have developed very fast code to get timing information based on TSC if available. It's all ocaml but well documented and mostly just calls to c functions so should be easy to port to C and we release it under a very liberal license so

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann bgrundm...@janestreet.com wrote: I posted this on this mailing list before at Jane Street we have developed very fast code to get timing information based on TSC if available. It's all ocaml but well documented and mostly just calls to c

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann bgrundm...@janestreet.com wrote: I posted this on this mailing list before at Jane Street we have developed very fast code to get timing information based on TSC if available. It's all ocaml but well documented and mostly just calls to c

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Thu, May 15, 2014 at 11:31 AM, Greg Stark st...@mit.edu wrote: On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann bgrundm...@janestreet.com wrote: I posted this on this mailing list before at Jane Street we have developed very fast code to get timing information based on TSC if

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On 2014-05-15 12:04:25 +0100, Benedikt Grundmann wrote: On Thu, May 15, 2014 at 11:31 AM, Greg Stark st...@mit.edu wrote: On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann bgrundm...@janestreet.com wrote: I posted this on this mailing list before at Jane Street we have developed

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Hi, On 2014-05-13 18:58:11 -0400, Tom Lane wrote: Anyway it looks like clock_gettime() might be worth using on Linux just for the more precise output. It doesn't seem to exist on OS X though, and I have no idea about elsewhere. Agreed that using clock_gettime() would be a good idea. I'd say

Re: [HACKERS] gettimeofday is at the end of its usefulness?

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

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Wed, May 14, 2014 at 6:34 AM, Greg Stark st...@mit.edu wrote: I always assumed the kernel used rdtsc to implement some of the high performance timers. It can save the current time in a mapped page when it schedules a process and then in the vdso syscall (ie in user-space) it can use rdtsc

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Tue, May 13, 2014 at 11:34 PM, Greg Stark st...@mit.edu wrote: I always assumed the kernel used rdtsc to implement some of the high performance timers. It can save the current time in a mapped page when it schedules a process and then in the vdso syscall (ie in user-space) it can use rdtsc

[HACKERS] gettimeofday is at the end of its usefulness?

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

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Tue, May 13, 2014 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote: There's also a CLOCK_REALTIME_COARSE selector, which is noticeably faster --- about 10nsec for me --- but the output appears to only advance once every millisecond, so it's probably useless for our purposes. The other

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Peter Geoghegan p...@heroku.com writes: On Tue, May 13, 2014 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote: There's also a CLOCK_REALTIME_COARSE selector, which is noticeably faster --- about 10nsec for me --- but the output appears to only advance once every millisecond, so it's probably

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Tue, May 13, 2014 at 11:58 PM, Tom Lane t...@sss.pgh.pa.us wrote: I also tried a loop around a bare rdtsc assembly instruction, finding that that instruction takes about 10nsec. That would be a nice improvement over gettimeofday, except that using that directly would involve dealing with

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Greg Stark st...@mit.edu writes: I actually think it would be more interesting if we could measure the overhead and adjust for it. Actually, that's quite a good thought. The overhead should be a pretty stable number on any given machine, so in theory we could do this to high precision. And

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Tuesday, May 13, 2014, Tom Lane t...@sss.pgh.pa.us 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