On Tue, Dec 26, 2023 at 11:27:16AM +0300, Nazir Bilal Yavuz wrote: > 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.
I am not sure while the whole point of the exercise is to have all the I/O related data in a single view. Something that I've also found a bit disturbing yesterday while looking at your patch is the fact that the operation size is guessed from the context and object type when querying the view because now everything is tied to BLCKSZ. This patch extends it with two more operation sizes, and there are even cases where it may be a variable. Could it be a better option to extend pgstat_count_io_op_time() so as callers can themselves give the size of the operation? The whole patch is kind of itself complicated enough, so I'd be OK to discard the case of the WAL receiver for now. Now, if we do so, the code stack of pgstat_io.c should handle WAL receivers as something entirely disabled until all the known issues are solved. There is still a lot of value in tracking WAL data associated to the WAL writer, normal backends and WAL senders. -- Michael
signature.asc
Description: PGP signature
