Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal
Shinya Kato <shinya11.kato@gmail.com>
From: Shinya Kato <shinya11.kato@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-23T09:36:01Z
Lists: pgsql-hackers
Attachments
- v2-0001-Add-wal_fpi_bytes-to-pg_stat_wal.patch (application/octet-stream)
- v2-0002-Expose-WAL-FPI-byte-totals-in-EXPLAIN.patch (application/octet-stream)
On Wed, Oct 22, 2025 at 5:45 PM Michael Paquier <michael@paquier.xyz> 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