Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal
Date: 2025-10-22 08:44:38
Message-ID: aPiZdu_jqEl2w1FN@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 22, 2025 at 05:04:58PM +0900, Shinya Kato wrote:
> The 0001 patch adds these columns to pg_stat_wal. The 0002 and 0003
> patches add this information to EXPLAIN (WAL) and pg_stat_statements,
> respectively. I don't think these additions (0002 and 0003) are
> mandatory, so I suggest we focus the discussion on the 0001 patch
> first.

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.

> Thoughts?

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.

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.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-10-22 08:48:33 Re: Question about InvalidatePossiblyObsoleteSlot()
Previous Message Jelte Fennema-Nio 2025-10-22 08:41:49 Re: CI: Add task that runs pgindent