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
