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 via pgsql-hackers ma
* 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 other two have perhaps
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 awhile and could not convince myself that it's
> a
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 s/gettimeofday/clock_gettime/g is not
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
>> and at least as of that commit, only x86 and x86_
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 for CLOCK_SECOND whic
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 perhaps 10ns resolution (I
* 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 i
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
>>> a library requirement, -lrt), and we woul
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 also need a way to
> pro
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 clockid; we at least need
e
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 logic to gettimeofday functi
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 06:58:11PM -0400, Tom Lane wrote:
> A recent question from Tim Kane prompted me
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 the overhead
costs of EXPLAIN ANALYZE, which I'd n
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 we had that presumably the
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 moot point.
Yeah, both Andres
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 I'd not checked in awhile. Things
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. Things
>>> are far worse than I t
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 thought. On my current
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.
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 sa
On 2014-05-15 12:04:25 +0100, Benedikt Grundmann wrote:
> On Thu, May 15, 2014 at 11:31 AM, Greg Stark wrote:
>
> > On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann
> > wrote:
> > > I posted this on this mailing list before at Jane Street we have
> > developed
> > > very fast code to get timi
On Thu, May 15, 2014 at 11:31 AM, Greg Stark wrote:
> On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann
> 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
On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann
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 functions so should
> be ea
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
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 it
On Tue, May 13, 2014 at 11:34 PM, Greg Stark 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 to calcula
On Wed, May 14, 2014 at 6:34 AM, Greg Stark 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 to calculat
On Tuesday, May 13, 2014, 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 simpl
Greg Stark 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 the numbers I
On Tue, May 13, 2014 at 11:58 PM, Tom Lane 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 cross-CPU skew
Peter Geoghegan writes:
> On Tue, May 13, 2014 at 3:58 PM, Tom Lane 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
On Tue, May 13, 2014 at 3:58 PM, Tom Lane 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
> selectors mentioned in
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
34 matches
Mail list logo