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
