Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 4 Nov 2025 16:13:55 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tomas Vondra <tomas@vondra.me>
Cc: Corey Huinker <corey.huinker@gmail.com>,
	jian he <jian.universality@gmail.com>,
	pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Subject: Re: Extended Statistics set/restore/clear functions.[
Message-ID: <aQmns_eQoiQ-92KA@paquier.xyz>
References: 
 <CADkLM=cuVMUNsv+C7dGUrc8zF2c4C_LXBcPCtb_zHR0z+fmb1A@mail.gmail.com>
 <CADkLM=eM0VA-muiu+JMM4-B8eL5ZscPeGtTxh7UtmM+iVO7C=A@mail.gmail.com>
 <CADkLM=daHJhUf-sO1iD=UTaymbBVEgEW4Sxm8PtHWWDEGWW9jQ@mail.gmail.com>
 <CADkLM=d_=STa4RHWHk7AGZ1RAZYKMtJxGMsw0Mrdb8s6CHdvbw@mail.gmail.com>
 <CADkLM=f2B8cDpx3V2bZW07GN5JHaP7kFe7G0cmJMSPVUQ4eHhQ@mail.gmail.com>
 <CADkLM=cWJTOnhC4jbKUvFgjMd=Hc252FXbampsjuYekBvmMVAg@mail.gmail.com>
 <aPcetUfI2NJDqYxZ@paquier.xyz>
 <CADkLM=efY2h8Bio=bE8O2Tnd=WUdyKDL1Zrtz9h+at16E4HVUA@mail.gmail.com>
 <aPls00-bu3fPcuk-@paquier.xyz>
 <439a9947-e6a1-4ea9-84d8-1f843deaf6b1@vondra.me>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="X+RxfDdQ3J71uiXA"
Content-Disposition: inline
In-Reply-To: <439a9947-e6a1-4ea9-84d8-1f843deaf6b1@vondra.me>
Archived-At: 
 <https://www.postgresql.org/message-id/aQmns_eQoiQ-92KA%40paquier.xyz>
Precedence: bulk


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

On Fri, Oct 31, 2025 at 09:22:55PM +0100, Tomas Vondra wrote:
> Sorry for not paying much attention to this thread ...

It was PGEU last week, it's not surprising knowing that you are in..
Europe :)

> My opinion is that we should both use the new format and keep the
> pg_dump code to allow upgrading from older pre-19 versions.

Okay, thanks for the input.

> There really is nothing special about the current format - I should have
> used JSON (or any other established format) from the beginning. But I
> only saw that as human-readable version of ephemeral data, it didn't
> occur to me we'll use this to export/import stats cross versions. So if
> we need to adjust that to make new use cases more convenient, let's bite
> the bullet now.
>=20
> If doing both is too complex / ugly, I think the pg_upgrade capability
> is more valuable. I'd rather keep the old, less convenient format to
> have pg_upgrade support for all versions.

Hmm.  I have been eyeing at the dump code once again, and it's not
that bad on a second lookup, so I'd be OK to incorporate the whole in
a review.

> Otherwise users may not benefit from this pg_upgrade feature for a
> couple more years. Plenty of users delay upgrading until the EOL gets
> close, and so might be unable to dump/restore extended stats for the
> next ~5 years.

Okay.

I still think that we should split things a bit more in the patch set.
Corey has sent me a proposal in this direction, where most of the
entries can be reviewed and potentially applied separately:
1. pg_ndistinct output function change.
2. pg_ndistinct input function addition.
3. pg_dependencies output function change
4. pg_dependencies input function
5. Expose attribute statistics function and rename them attstat_* or
statatt_*
6. pg_restore_extended_stats
7. pg_dump with no ability to fetch old-format
pg_ndistinct/pg_dependences.
8. pg_dump working back as far as possible

I am not completely sold about the changes in the input/output
functions, but I'd be happy to consider more options with a rebased
patch set (with the dump issue on older clusters issue, while on it).
--
Michael

--X+RxfDdQ3J71uiXA
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmkJp7MACgkQnvQgOdby
QH0b+Q/9G4eMgFSRG0hW2x5zeiPOVGAn7AtI2vtT9bSBtEyrPgmneP6WRxOQrnpn
r/1kI0d66NKM83F2Zv5Pds297oNoW5eNRDq8UgCIBH1dh57zjemGS8fhOV0jZnhe
VItoqBA4Ht4CsHqdvDAz8+Hd3YO05r1QTY3yz4J8dcmNlrpgO+rrak5/rWsFnUd9
eAuDOFHGMYBbDB1KEmcMGTQiYaZlFR9jmhdvDDDgBeRl+82d/OkDMXJ7kMGjU5n6
vyojicQMr/3c4hVg3xccU1l/hrQ+2e4Cpgw/f2TN0AM+GdVCYe7ey3I47af4l6CC
SQTeFOlTnCmfrMlAAJ/D1MwrS42s0NDCQAIUt6d0OZGXclkGaqT+NkO08q8mv4Go
H7ZBZTccmnxbrrfcu61dNLFfdS0Gr+w9rWFAhbqk+LRjsV7oXndPUb4uvnZ8reQE
6nDpRfWzBez/W1P0GIQU4e7KUir7Ok3vIvIb8oVejDdfgf8OABtbToru51MvbYKW
i+df05ye+gkqMcVed+gm6eLxzV85FTR96HWPiAQB2mbwbAzfBzMHKrGxAZuXzhS9
pJxlYLOCRWplY7dVGmIxDMy8nhBp8jUEucZjVYYSrg3+Fjy4kK0mRJjU/1YqQ7NP
EyUcVotOxJiAvMdeIsyYISVFlVdVemEIzPyXMpGgCc/Kt+H+BMY=
=I5j/
-----END PGP SIGNATURE-----

--X+RxfDdQ3J71uiXA--