Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 16 Dec 2025 16:33:17 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Kirill Reshke <reshkekirill@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <aUELPdhdcyzTM_8K@paquier.xyz>
References: <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>
 <aN3T_5NBv0XKFbs7@paquier.xyz>
 <aQ3X20hbqoThQXgp@ip-10-97-1-34.eu-west-3.compute.internal>
 <aQ_TYhsZG72QkS_A@paquier.xyz>
 <aRGoGcOdutTHQfpn@paquier.xyz>
 <aRS9+yaGhjDslRWj@ip-10-97-1-34.eu-west-3.compute.internal>
 <aUA3XkU9hc1xrtRB@ip-10-97-1-34.eu-west-3.compute.internal>
 <ezbfcpjtfh3vtm667aegyrptcdsvinbuxw6y5p6j3e5fbffrl5@i7v6cjapz3yv>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Uy3Hzvgbrximgwu8"
Content-Disposition: inline
In-Reply-To: <ezbfcpjtfh3vtm667aegyrptcdsvinbuxw6y5p6j3e5fbffrl5@i7v6cjapz3yv>
Archived-At: 
 <https://www.postgresql.org/message-id/aUELPdhdcyzTM_8K%40paquier.xyz>
Precedence: bulk


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

On Mon, Dec 15, 2025 at 12:48:25PM -0500, Andres Freund wrote:
> I don't think this is true as stated. Two reasons:
>=20
> 1) This afaict guarantees that the relfilenode will not clash with oids, =
but
>    it does *NOT* guarantee that it does not clash with other relfilenodes
>=20
> 2) Note that GetNewRelFileNumber() does *NOT* check for conflicts when
>    creating a new relfilenode for an existing relation:
>  * If the relfilenumber will also be used as the relation's OID, pass the
>  * opened pg_class catalog, and this routine will guarantee that the resu=
lt
>  * is also an unused OID within pg_class.  If the result is to be used on=
ly
>  * as a relfilenumber for an existing relation, pass NULL for pg_class.

FWIW, I am also still troubled by the part of the proposed patch set
where we are trying to hide the idea of a partitioned table has a
relfilenode set by using its relid instead in the key for the data.
This leads to a huge amount of complexity in the patch, mainly to
store data for autovacuum that we do not need at the end:
- autovacuum discards partitioned tables in do_autovacuum(), so the
stats related to partitioned tables that we need to select the
relations does not matter.
- manual vacuums may include partitioned tables to extract its
partitions, vacuum_rel() at the end discarding them.  Well, stats
don't matter anyway.

We only need to attach three fields to let autovacuum know if a
relation needs to run or not: dead_tuples, ins_since_vacuum,
mod_since_analyze.  Most the fields of PgStat_StatTabEntry make sense
only for tables, few are required by indexes for pg_stat_all_indexes.
Some fields actually make sense because they refer to on-disk files,
mostly for pg_statio_all_tables (blocks_fetched, blocks_hit).

Hence, why don't we split PgStat_StatTabEntry into three things from
the start, even if it means to duplicate some of them?  Say:
- Table fields: includes [auto]vacuum/analyze data, block fields,
fields of pg_stat_all_tables.
- Index fields: no need for the [auto]vacuum/analyze time and counts,
block fields, pg_stat_all_indexes fields.
- Relfilenode fields: dead_tuples, ins_since_vacuum and
mod_since_analyze.  Does not apply to partitioned tables and indexes,
only applies to tables.  Provides a clean split, embrace the fact that
these are the only three fields we need to worry about during
recovery.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmlBCz0ACgkQnvQgOdby
QH2dGQ/8D2aA2Ef4d7m/z0s7NQp4g5tjrsLuslGSAIwdrTn5Xc70lVFiCsAYJXz4
P8JPh4/35hx4PBHMHLqJ4TUYmZf1nc9kQ7HVJtp9k9zO4ycWBPmUtPOMQZbTmsGv
uUximX3qUMGngtdwm+xxKqELBbYCgND8/h7J2QPjhkdhlKZRwMuy6X07Y7TUW1wA
1Zl3HNSuZ8RRaGfhsH1w7DwWXvzPSpel94ViY+Dx5adimVbOYcYqydY/7CXDSSAw
xST1CajaoFIVCZsuIu9bilDgENFvrrRXUlE9rn1dYDmC3xImQpLeLJF0ZtB/bdcD
1fHeeac+7fcBT7W+loiJY5wBpQqRBJKIAoMSs2MeiSKzFA0jPqsHUmWizlbr/on9
pYJhcP+KPdd3DsaDmxZnt5gggZejrhW6xZXrE5ohOqQvPbD7+/2RCWKakWkbUiiT
+OwMnys+EAgAwsiyu77GXLBaPnWGa5HxSIiJpP0Fm1faVKGCxRENEk3g1L78jK65
C6BOhiaMJ3KXypTWDBWwHJ0+AkavUJ58XbjAL/W6T4aiRoSDe2U2uF/iY4wpOaoj
ttlIlwabrVo2aj8QaZyIAqgJgw+lZGd5cQs+kbeqHevT2Soeli9kHRQ6syUXhH4w
5ccgJqP3okjsC2WVog73gxL6IDYhQQwnURGl0o2Dzimgs9nnPas=
=OEiZ
-----END PGP SIGNATURE-----

--Uy3Hzvgbrximgwu8--