On Wed, Dec 22, 2021 at 11:16 AM Stephen Frost <sfr...@snowman.net> wrote: > > I set "track_io_timing" to "on" all the time, same as "log_lock_waits", > > so I'd want them both on by default. > > Same. I'd also push back and ask what modern platforms still require a > kernel call for gettimeofday, and are we really doing ourselves a favor > by holding back on enabling this by default due to those?
+1 > If it's such > an issue, could we figure out a way to have an 'auto' option where we > detect if the platform has such an issue and disable in that case, but > enable otherwise? This is the same principle behind wal_sync_method's per-platform default, of course. Seems like a similar case to me. I think that the following heuristic might be a good one: If the platform uses clock_gettime() (for INSTR_TIME_SET_CURRENT() stuff), then enable track_io_timing by default on that platform. Otherwise, disable it by default. (Plus do whatever makes the most sense on Windows, which uses something else entirely.) The issue with gettimeofday() seems to be that it isn't really intended for the same purpose as clock_gettime() -- it's just for getting the time, not measuring elapsed time. It seems reasonable to suppose that an operating system that offers a facility for measuring elapsed time won't have horrible performance problems. clock_gettime() first appeared in POSIX almost 30 years ago. -- Peter Geoghegan
