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

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