Thanks, Justin, for the report On Thu, Jul 16, 2026 at 11:03 AM Andrey Rachitskiy <[email protected]> wrote: > > With track_io_timing=on, foreign IO wait time is currently recorded: when > WaitReadBuffers() waits on foreign_io, it calls pgstat_count_io_op_time() > with cnt=0. So we do write non-zero IOOP_READ time into this backend's > pending pg_stat_io stats, without incrementing the read count in this backend. > > Thus, this fix introduces a real change: it disables recording foreign IO > wait time in pg_stat_io statistics for the backend that is performing the > wait. > > What we lose is only that wait time. The initiating backend still records the > read count and its own IO time, and the waiting backend still records a > buffer hit once the IO completes.
Yea, so, I don't think we can just not record the wait time for foreign IOs. For asynchronous reads, read time in pg_stat_io is almost entirely wait time. That's also why it doesn't make sense to have a separate IOOP_WAIT -- unless we start measuring and displaying read latency (how long the actual reads took) in pg_stat_io and then you could separate that from wait time. My first thought is that we should relax the restriction in pgstat_bktype_io_stats_valid() that requires non-zero counts if time is non-zero. But that seems silly: 1) we lose lots of validation for cases where this would be bogus and 2) anyone looking at the view that seems non-zero IO time and 0 count will be very confused and 3) it makes any math dividing read time by read operations meaningless (though I don't know how meaningful that is now). If read time is truly just wait time, we could just pass pg_stat_count_io_op_time() a count of 1 for foreign IO in WaitReadBuffers(). In 19, we should likely either do this or do as Andrey suggested and not count the wait time for foreign IOs. For master, I'd like to do something more satisfying, but I'm not sure what. It did get me thinking that there is 0 way for the user (or developer) to know about foreign IOs. Maybe that's okay...? - Melanie
