On Fri, Jan 12, 2024 at 04:23:26PM +0300, Nazir Bilal Yavuz wrote: > On Thu, 11 Jan 2024 at 17:28, Melanie Plageman <melanieplage...@gmail.com> > wrote: >> Even if we made a separate view for WAL I/O stats, we would still have >> this issue of variable sized I/O vs block sized I/O and would probably >> end up solving it with separate columns for the number of bytes and >> number of operations. > > Yes, I think it is more about flexibility and not changing the already > published pg_stat_io view.
I don't know. Adding more columns or changing op_bytes with an extra mode that reflects on what the other columns mean is kind of the same thing to me: we want pg_stat_io to report more modes so as all I/O can be evaluated from a single view, but the complication is now that everything is tied to BLCKSZ. IMHO, perhaps we'd better put this patch aside until we are absolutely *sure* of what we want to achieve when it comes to WAL, and I am afraid that this cannot happen until we're happy with the way we handle WAL reads *and* writes, including WAL receiver or anything that has the idea of pulling its own page callback with XLogReaderAllocate() in the backend. Well, writes should be relatively "easy" as things happen with XLOG_BLCKSZ, mainly, but reads are the unknown part. That also seems furiously related to the work happening with async I/O or the fact that we may want to have in the view a separate meaning for cached pages or pages read directly from disk. The worst thing that we would do is rush something into the tree and then have to deal with the aftermath of what we'd need to deal with in terms of compatibility depending on the state of the other I/O related work when the new view is released. That would not be fun for the users and any hackers who would have to deal with that (aka mainly me if I were to commit something), because pg_stat_io could mean something in version N, still mean something entirely different in version N+1. -- Michael
signature.asc
Description: PGP signature
