Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 27 Mar 2026 11:59:33 +0900
From: Michael Paquier <michael@paquier.xyz>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [Proposal] =?utf-8?B?cGdfc3RhdF93YWxf?=
 =?utf-8?B?cmVjb3JkcyDigJM=?= per-record-type WAL generation statistics
Message-ID: <acXylU7iQ4P_YbGD@paquier.xyz>
References: 
 <CAHg+QDcE2zrcQqA2aE2SNxVnPNHG5WkOeDve8G2+gLT20_G3JA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="bv2ThYkD1lLrmxwW"
Content-Disposition: inline
In-Reply-To: 
 <CAHg+QDcE2zrcQqA2aE2SNxVnPNHG5WkOeDve8G2+gLT20_G3JA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/acXylU7iQ4P_YbGD%40paquier.xyz>
Precedence: bulk


--bv2ThYkD1lLrmxwW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 26, 2026 at 05:29:25PM -0700, SATYANARAYANA NARLAPURAM wrote:
> Postgre already has pg_stat_wal for aggregate WAL volume (bytes, full-page
> images, buffers), and pg_walinspect (superuser access required) for
> post-hoc forensic analysis of individual WAL segments. But I don't see a
> lightweight, observability tool that answers in real time which record
> types are responsible for the WAL. Additionally, pg_walinspect runs again=
st
> on-disk WAL files, which is expensive. This view will be useful for
> monitoring systems to poll cheaply.
>=20
> *Use cases:*
> WAL volume investigation: see which record types dominate WAL generation =
in
> real time without touching disk.
> Monitoring integration: Prometheus/Grafana can poll the view to track WAL
> composition over time and alert on anomalies.
> Replication tuning: identify whether WAL volume is dominated by data
> changes, index maintenance, FPIs, or vacuum activity to guide tuning.
> Extension debugging: custom WAL resource managers get visibility
> automatically.

Why is it useful to have access to this information in live for
monitoring purposes, divided by RMGR?  What do you define as an
anomaly in this context and what can be changed on the server side to
get out of an anomaly, based on the definition you would give to it?

The current WAL and IO stats are directly useful because they provide
numbers about flush, read and write quantity and timings.  These are
useful metrics for benchmarking.

This proposal only informs about the number of records, and we have a
various number of record types that have a variable length, that can
influence the distribution of the data written on disk.

As a whole, I am doubtful that this information is worth counting in
live, eating a stats kind ID.  One could also implement a background
worker that provides more advanced aggregate stats outside the WAL
insert path, with a custom stats kind.  No need to have that into
core, especially if the code that increments the stats eats more and
more cycles.
--
Michael

--bv2ThYkD1lLrmxwW
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmnF8pUACgkQnvQgOdby
QH0qxw/+MtVJiu8qc94GB7SIAm1e96EGW/IUPz8fzVJORBNKTPWGA4tD6kueV2hR
ZQBq8Gzep/VrOCimJveID2DsmV1JsFToAdChF4BiAtZ+hSbAD5zwN8Z56tA8/+3M
ieeG/EM5aFk+TYzWXTR4fLHnXtCfKXlHKR1vqH8QNIZZsq5e3Z6IxGEs+uHVeFgc
XjjoXh8vVOiD74Oo1xd0C/jhdIAcyUwITGUoI5+hLhqsBVpPtT4puutPhzi7E2XH
qczOZ0f8kMXFtgQEhPmm4HA4X9TSOEDtTXuK5drTT971YFawUF5sZF+pRjnBkoRX
RNBv0GHMz+vVi99zS+6qASjZKtdRsKUFFypA/GznTXKpGLA7CNjZ2lN735BlC66N
2YeHqokxOrC0zvF0VGYrxc44vpjkCzFuJxgVh/iRRImzeKbCcpuqLlYHy+9YgGuQ
MnojdUj17KYO6umMOpZ7D2BUTNzCzsG8ri8TWPXcy5YfLB746fBgGdGltUfaTeJ2
Li9W9c8E0P9Itop6XDqtZO4LOPfKSfxlcPo3lp4wnCTOHPKJtcsKfLuMs91gB1HF
2ztPVHrz4p3eIPdeMV87cpwExrJ+G/tw/KDAohTAHMKNyjb1Gu9Y+OSl9BNSwV8m
5FyYqFomEuFD0wfNPIw7CRSSHUWlMwje+kobNxJZySNFrvfLYkA=
=q+RZ
-----END PGP SIGNATURE-----

--bv2ThYkD1lLrmxwW--