Haribabu Kommi <kommi.harib...@gmail.com> 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 function call.
Well, of course, configure is the hard part. I got interested in this area again pursuant to a question from Joel Jacobson, and looked around to see if things had changed any since 2014. One pleasant surprise is that Apple got around to implementing clock_gettime() as of the current macOS release (10.12 "Sierra"). That means that pretty much all interesting platforms now have clock_gettime(), which removes one possible objection to starting to use it. However, it seems like there is not a lot of commonality to the best "clockid" to use. In theory, according to the POSIX spec, CLOCK_MONOTONIC would be what we want to use for time interval measurement (EXPLAIN ANALYZE), since that would be impervious to possible clock setting changes. But some implementations might only optimize the more common CLOCK_REALTIME, and I found that there are a lot of platform-specific clock IDs that we might want to consider. 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. On macOS (10.12.2, 2.7GHz x86_64), clock_gettime(CLOCK_REALTIME) is actually a shade faster than gettimeofday: 40ns versus 46ns. But it's only giving 1us resolution, no better than gettimeofday. CLOCK_MONOTONIC is also 1us and it takes 75ns to read. But there's a CLOCK_MONOTONIC_RAW that takes 44ns to read and seems to offer full precision -- no duplicate readings in a tight loop. There's also CLOCK_MONOTONIC_RAW_APPROX which can be read in 23ns but the resolution is only around half an ms. 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 which is intentionally truncated to 1s precision. So there would be no need to work with anything but CLOCK_MONOTONIC here. 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_64 had the fast clock_gettime code. Older FreeBSD, or FreeBSD on another architecture, is likely to be a lot worse. But I lack an installation to try. I also tried OpenBSD 6.0 on that same Mac, and got pretty horrid results: gettimeofday, CLOCK_REALTIME, and CLOCK_MONOTONIC all take about 613ns to read. Ouch. And so does time(NULL); double ouch. Evidently there's no optimization on this platform and what we're seeing is the minimum cost for a kernel call. Still, we do get better precision from clock_gettime than gettimeofday, so we might as well switch. 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 enough smarts to use CLOCK_MONOTONIC_RAW on macOS. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers