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
