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 > selectors mentioned in the Linux man page are considerably slower than > CLOCK_REALTIME for me, suggesting that they actually call into the kernel.
What Linux kernel version is in use here? Apparently, as I think you've stated another way, more recent versions have VDSO for this, which can make a big difference. This article seems like a sensible guide to all of this: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-gettimeofday_speedup.html CLOCK_REALTIME_COARSE seemingly influences precision in a way that allows user space applications to decide on their precision/cost trade-off, rather than being forced to use the system default (that procfs surfaces) through gettimeofday(): http://lwn.net/Articles/342018/ I can see a benefit in exposing this trade-off to Postgres code directly. I still think that a correlated reference period will prove useful, and while there are a number of ways to amortize the cost of repeatedly (coarsely) getting the wall time in the ordinary course of choosing victim buffers, it would be nice to do this too. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
