From: | Florian Weimer <fw(at)deneb(dot)enyo(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gettimeofday is at the end of its usefulness? |
Date: | 2016-12-29 20:02:49 |
Message-ID: | 87y3yyfqqe.fsf@mid.deneb.enyo.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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 in a tight loop). Other documented clockids include
> CLOCK_REALTIME_COARSE: about 10ns to read, but only 1ms resolution
> CLOCK_MONOTONIC_COARSE: about 12ns to read, but only 1ms resolution
> CLOCK_MONOTONIC_RAW: full resolution but very slow, ~145ns to read
> So CLOCK_MONOTONIC seems to be the thing to use here. It won't buy
> us anything speed-wise but the extra resolution will be nice.
> However, we need to do more research to see if this holds true on
> other popular distros.
Isn't this very specific to kernel and glibc versions, depending on
things like CONFIG_HZ settings and what level of vDSO support has been
backported?
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2016-12-29 20:15:36 | Re: proposal: session server side variables |
Previous Message | Pavel Stehule | 2016-12-29 19:51:01 | Re: proposal: session server side variables |