Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 2 Oct 2025 10:23:11 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <aN3T_5NBv0XKFbs7@paquier.xyz>
References: 
 <CALdSSPhQyvK_wsvV+HiQcC6f57Zg2WO60wxv=CXbcoZ1p5HHEQ@mail.gmail.com>
 <Z0nbomp2e/L30WDA@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPhFaLEWXG9Mn8-tZoS68rE52647a2oZ6jrUNSBtwadD0A@mail.gmail.com>
 <Z07d850Yp7Sd9Qqq@ip-10-97-1-34.eu-west-3.compute.internal>
 <Z3gN3bwUMijyV4I0@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPh76=ACN=z68oM44ZMgZsQxTTYVF8qvi1F6TGA5Mn6uiQ@mail.gmail.com>
 <aMkHSeitgUPtMyA2@paquier.xyz>
 <aNutZbziBycskOYR@ip-10-97-1-34.eu-west-3.compute.internal>
 <aNxiLG0JTCYnpqx6@paquier.xyz>
 <aN07p71KNFR2HdaD@ip-10-97-1-34.eu-west-3.compute.internal>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="7D3EaSYzB4FSFYHo"
Content-Disposition: inline
In-Reply-To: <aN07p71KNFR2HdaD@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/aN3T_5NBv0XKFbs7%40paquier.xyz>
Precedence: bulk


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

On Wed, Oct 01, 2025 at 02:33:11PM +0000, Bertrand Drouvot wrote:
> I think the first step is to replace (i.e get rid) PGSTAT_KIND_RELATION b=
y a brand
> new PGSTAT_KIND_RELFILENODE and move all the existing stats that are curr=
ently
> under the PGSTAT_KIND_RELATION to this new PGSTAT_KIND_RELFILENODE.

Likely so, yes.

> Let's do this by keeping the pg_stat_all_tables|indexes and pg_statio_all=
_tables|indexes
> on top of the PGSTAT_KIND_RELFILENODE and ensure that a relation rewrite =
keeps=20
> those stats. Once done, we could work from there to add new stats (add wr=
ites
> counters and ensure that some counters (n_dead_tup and friends) are repli=
cated).

Do you think it is OK to define non-transactional pending stats as
being always a subset of the transactional stats?  I don't quite see=20
if there would be a case to have stats that are only flushed in a
non-transactional path, while being discarded at the stats report done
at transaction commit time.  This means that it may be possible to
structure things so as the pending non-transaction stats structure are
always part of the transactional bits, and that the other way around
is not possible.  Perhaps that influences the design choices, at least
a bit.
--
Michael

--7D3EaSYzB4FSFYHo
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmjd0/8ACgkQnvQgOdby
QH22vQ/+ImHm8dzABVUWM53973S5rQNZcPM1xBJeexSFjSjq5d3vtuzaXiis7v5W
c/w850+z3A9wwr897j6F2boQm0TbaKKsRlgFhKV4jhTY3bW54IKdsAOA+BKlwpgJ
x7TqHwDde4sDhyHU1iYn9fUrl/a4dj8q+C319MQuLJOh7dovNPD0zO2Up/r+Z+8n
LXZ7TcO30evL2Jr1aPw3dYYgyKj0nDGGc0Pnqt/XFxsfuqP+FLcM9QBQab80bT4i
jhDuWVZw+q4h6ctz3IVLM+rL6dH5lG8aDV3P0l1Vc8sjhehX8F33OuepakssByby
TYX9KmTrjyXDqcWzO5x0hQPF1Pikk/KGZg1+aroNT1ORLxqGBMynzgCpX4GlYOY/
ibiWsiVgBCnKdwzoA0vzz8PTogOKZxp1aNhRI8u26vpC22W3OouKuPSBcGo2MHIk
noGe+oZIuifVJ/8TBP9M7h2+ihpVtvCg3LTo2vYFgR3wdzy2cwDFLfAsHuOEyCPH
NsR1DMEK9JxaBXWu/zRRisk0YGoJCLkff5UP0ZxjRAkMOEYnGrbGWW6VU6f9GtV1
uKjkY1/7iPGLvqqOP1+xFfbc4ct8vhASuysXEGDjdR7tUkeL1EZobl7BjJRDHDws
mwcHifUYJYHGXy5Wv7Zpl1uGV0qxNWnaeU0LuptwT6/fQPZ0mg8=
=LeOq
-----END PGP SIGNATURE-----

--7D3EaSYzB4FSFYHo--