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? >> The other alternative I see is to use XLOG_BLCKSZ as the op_bytes and >> treat op_bytes * number of reads as an approximation of the number of >> bytes read. I don't actually know what makes more sense. I don't think I >> would like having a number for bytes that is not accurate. > > Also, we have a similar problem in XLogPageRead() in xlogrecovery.c. > pg_pread() call tries to read XLOG_BLCKSZ but it is not certain and we > don't count IO if it couldn't read XLOG_BLCKSZ. IMO, this is not as > important as the previous problem but it still is a problem. > > I would be glad to hear opinions on these problems. Correctness matters a lot for monitoring, IMO. -- Michael
signature.asc
Description: PGP signature