On Wed, Oct 22, 2025 at 5:45 PM Michael Paquier <[email protected]> wrote: > We already know the number of FPIs generated. Hence my take would be > to use only one counter, not two: an aggregated FPI length like in > xlogstats.h as exposed in pg_walinspect. That should be enough to > offer trends regarding the effects of compression, even if some pages > have holes that are discarded.
Yeah, I would like to know the trends of FPI compression rates, not the exact FPI compression rates. So, I agree with Michael, and have updated the patches. > I would suggest to leave PGSS out of it for now. We really need to do > something about the number of fields computed, with more GUCs to > disable groups of them, at least, like JIT or the planning parts. No > objections for the EXPLAIN and pg_stat_wal parts. Okay, since I'm not strongly attached to this idea, I've removed the 0003 patch for now. > The patch can be simpler. There is no need to pass the calculated > number(s) across multiple functions in the stack, you can just > aggregate the numbers in pgWalUsage directly in XLogRecordAssemble(). > The only extra thing to do is that one needs to set > pgstat_report_fixed to true to force the report to pgstats. Thank you for your review. I've implemented this suggestion in the v2 patches. -- Best regards, Shinya Kato NTT OSS Center
v2-0001-Add-wal_fpi_bytes-to-pg_stat_wal.patch
Description: Binary data
v2-0002-Expose-WAL-FPI-byte-totals-in-EXPLAIN.patch
Description: Binary data
