Hi, On 2026-02-03 12:44:21 -0500, Andres Freund wrote: > Hm. I think it'd make sense to use eventually use this clock source for other > timing tasks too, not just explain. E.g. pg_stat_statements could benefit > quite a bit from reducing the timing overhead. > > Whereas it'll not make sense for anything that needs wall clock times - which > imo makes a "clock_source" GUC misnamed. Maybe "clock_source_timing" or such?
I forgot another important one we really should use the fast timing for: track_io_timing/track_wal_io_timing. The overhead of IO timing can be noticeable on busy systems and it's hard to believe that the inaccuracy matters. This is probably particularly relevant when measuring IO intensive workloads where the data resides in the kernel page cache, but doesn't fit into s_b. Greetings, Andres Freund
