Hi, On Tue, 26 Dec 2023 at 03:06, Michael Paquier <mich...@paquier.xyz> wrote: > > On Mon, Dec 25, 2023 at 04:09:34PM +0300, Nazir Bilal Yavuz wrote: > > On Wed, 9 Aug 2023 at 21:52, Melanie Plageman <melanieplage...@gmail.com> > > wrote: > >> If there is any combination of BackendType and IOContext which will > >> always read XLOG_BLCKSZ bytes, we could use XLOG_BLCKSZ for that row's > >> op_bytes. For other cases, we may have to consider using op_bytes 1 and > >> tracking reads and write IOOps in number of bytes (instead of number of > >> pages). I don't actually know if there is a clear separation by > >> BackendType for these different cases. > > > > Using op_bytes as 1 solves this problem but since it will be different > > from the rest of the pg_stat_io view it could be hard to understand. > > There is no clear separation by backends as it can be seen from the > > walsender. > > I find the use of 1 in this context a bit confusing, because when > referring to a counter at N, then it can be understood as doing N > times a operation, but it would be much less than that. Another > solution would be to use NULL (as a synonym of "I don't know") and > then document that in this case all the bigint counters of pg_stat_io > track the number of bytes rather than the number of operations?
Yes, that makes sense. Maybe it is better to create a pg_stat_io_wal view like you said before. We could remove unused columns and add op_bytes for each writes and reads. Also, we can track both the number of bytes and the number of the operations. This doesn't fully solve the problem but it will be easier to modify it to meet our needs. -- Regards, Nazir Bilal Yavuz Microsoft
