On Tue, Feb 04, 2025 at 08:49:41AM +0000, Bertrand Drouvot wrote: > I think that: > > wal_write (and wal_write_time) > wal_sync (and wal_sync_time)
Right. We are not able to get this data from XLogWrite() and issue_xlog_fsync(), so there is no need to duplicate that anymore in your patch. > can be extracted from pg_stat_get_backend_io(), so there is no need to > duplicate > this information. The same comment could be done for pg_stat_wal and > pg_stat_io > though, but pg_stat_wal already exists so removing fields has not the same > effect. > > What are you thoughts about keeping in pg_stat_get_backend_wal() only the > 4 stats mentioned above? wal_buffers_full is incremented in AdvanceXLInsertBuffer(), part of PendingWalStats. wal_records, wal_fpi and wal_bytes are part of the instrumentation field. It looks to me that if you discard the wal_buffers_full part, the implementation of the data in the backend could just be tied to the fields coming from WalUsage. Actually, could it actually be useful to have wal_buffers_full be available in WalUsage, so as it would show up in EXPLAIN in a per-query basis with show_wal_usage()? Consolidating that would make what you are trying it a bit easier, because we would have the WalUsage and the pg_stat_io parts without any of the PendingWalStats part. And it is just a counter not that expensive to handle, like the data for records, fpis and bytes. This extra information could be useful to have in the context of an EXPLAIN. -- Michael
signature.asc
Description: PGP signature
