Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 10 Nov 2025 17:53:45 +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: <aRGoGcOdutTHQfpn@paquier.xyz>
References: <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>
 <aN3T_5NBv0XKFbs7@paquier.xyz>
 <aQ3X20hbqoThQXgp@ip-10-97-1-34.eu-west-3.compute.internal>
 <aQ_TYhsZG72QkS_A@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Xja6Q1McOKyKvRuw"
Content-Disposition: inline
In-Reply-To: <aQ_TYhsZG72QkS_A@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/aRGoGcOdutTHQfpn%40paquier.xyz>
Precedence: bulk


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

On Sun, Nov 09, 2025 at 08:33:54AM +0900, Michael Paquier wrote:
> Looking at this part of the patch set for now, not looked at the rest
> yet.  This new stats_1.out is 2k lines long, introduced for the tests
> related to rewrites as an effect of 2PC.  It seems to me that a split=20
> into a new stats_rewrite would be justified for this case, to reduce
> the output duplication.

The first patch had an issue with some of the tests checking for dead
tuples: if an autovacuum kicks in before querying the stats, we would
get a dead tuple number of 0.  So I have expanded the tests a bit to
avoid autovacuum interactions, which should be enough to avoid noise,
did a split into a new file, which should also be fine because we
don't rely on a system-wide stats reset, then applied the result.

The patch is spending a great deal of effort on three fronts:
- making sure that the statistics are copied over after a relation
rewrite.
- making sure that we assign a "correct" object ID, assigning
the fields of RelFileLocator based on a relation ID.  Mapped and
shared relations make the exercise a bit more difficult.  It would be
nice to avoid this kind of duplication with other code paths that
assign a RelFileLocator.
- Partitioned tables, where we don't have a relfilenode but we need to
track statistics.  The patch relies on the relation oid to assign a
key, as far as I've read.

Among the three points, the first one is the most invasive in the
patch, it seems, and do we actually want to keep the stats across
rewrites at all?  The main reason of doing the relfilenode move=20
would be to rebuild these stats on a WAL-record basis because the
relfile locator is the only thing we know in the startup process, and
once rewritten the state of the data is different.
relation_needs_vacanalyze() then cares about three fields:
- Number of dead tuples, which would be 0 after a rewrite.
- ins_since_vacuum, which would be 0 after a rewrite.
- mod_since_analyze, for analyze, again 0.

I have not checked the recent autovacuum scheduling thread to see if
this set changes there.

Are these numbers worth the effort of copying over at the end?  Was
this particular point discussed?  I've seen this mentioned once here,
but I am wondering what are the arguments in favor of copying the
stats data versus not copying it across rewrites:
https://www.postgresql.org/message-id/20240607031736.7izmr2yirznvidka%40awo=
rk3.anarazel.de
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmkRqBkACgkQnvQgOdby
QH3Ynw//VweH3wWmgaSED2PtB5eQc/68YO6gNrJbUPCQzw+RBuluujKZNyeRpSvE
+1e6+HMXku6mcRzIumQge2Ds8whkit3rQFiYPDs15hweOPkIQjxkkt+xm12fiClD
rItTo+Qn8wujMZuextyvi5IJyZ+DtdLGnqQuofhIfOemkx6Gges96lxnR4UyrJi3
ehaC821ouMYoBaW5GaSc/wQLvlr9qD/HJaJlcPEXUeDyxWbSKVQLPmHm9WzZAxEi
+RPByI5Uv7Mus7mw0aYMNSbY8GjTEiLSbSb6yQMGrHV0ypZfMcX6VcpKXCAL+cOi
CJHEeExGek1eIf7jffrDu9iSEAuTLP+Oc5uiA8U7oWXhLmNoQKaNOFwkfnsgjLcW
83lBG0pKsLzO5Rk/Ms2AO1KFAp7Umgi2k6maTgCAT6tPEgLdD5VresrH7Tw9dshQ
SzzEDOB6AVaoZclBnD2AzrxNPOUC7fDLa2zm3YPoH6v1Vi8/1wn8cWa4fV2CnJiA
bM+cMp0FfFTOvmaZI6NUi4Uy8wYIOHCRzY+/QbhqfwjKvDihWNPUyKoNH+tqzaN+
HszhYeEaR8WUqDz3iVT8Pmt0LMgHlaixeDLOoZprY2fZCpmizuHe/GZv2COrdxY9
Gjx5lHojrIs8BOKrjjQOS7tiRoAteDMDxHDgpj8tyBEDdPNiZek=
=QCGd
-----END PGP SIGNATURE-----

--Xja6Q1McOKyKvRuw--