Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 18 Nov 2025 12:34:29 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: jian he <jian.universality@gmail.com>, Tomas Vondra <tomas@vondra.me>,
	pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Subject: Re: Extended Statistics set/restore/clear functions.
Message-ID: <aRvpRaM44HRi0EIX@paquier.xyz>
References: 
 <CADkLM=c8-U4GLMw5VdeDdfp1ae6BW=PCfEQqAky04iZMbckCFw@mail.gmail.com>
 <CACJufxFo5b0FvmV4CmOb74NFrXm_znZHh7bLiiVkAzVzTnJiVw@mail.gmail.com>
 <CADkLM=fky861BrifcuWc0CbWfo3yMbRB+m1jG4qqXG_3hnqdtA@mail.gmail.com>
 <CACJufxFni1oB-VFuLbVs9VSgVx0czvoZyoW0z_tJ2kq4E3SXYw@mail.gmail.com>
 <CADkLM=d_mmTn3+ChL-z_ZomwOKT-BssQU+=6_a8WDv6A4b7uAA@mail.gmail.com>
 <aRbLV7Tru3ulO5ru@paquier.xyz>
 <aRrHBj7I4CeV21dj@paquier.xyz>
 <CADkLM=ei_07zDAyTrabZRc1tbRwzWLBd5yaP1zzqBTXxpvS-SA@mail.gmail.com>
 <aRutno2k5ilGCMIC@paquier.xyz>
 <CADkLM=d7fu9k03CD60eHciF3bUbd1-ANSD8VjVxsjMyAL1HVGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="exmKyYFTA1M18xbe"
Content-Disposition: inline
In-Reply-To: 
 <CADkLM=d7fu9k03CD60eHciF3bUbd1-ANSD8VjVxsjMyAL1HVGQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aRvpRaM44HRi0EIX%40paquier.xyz>
Precedence: bulk


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

On Mon, Nov 17, 2025 at 09:32:37PM -0500, Corey Huinker wrote:
> So I looked at the generator functions, hoping they'd have enough in comm=
on
> that they could be made generic. And they're just different enough that I
> think it's not worth it to try.
>=20
> But, if we don't care about the order of the combinations, I also don't
> think we need to expose the functions at all. We know exactly how many
> combinations there should be for any N attributes as each attribute must =
be
> unique. So if we have the right number of unique combinations, and they're
> all subsets of the first-longest, then we must have a complete set.
> Thoughts on that?
>=20
> Getting _too_ tight with the ordering and contents makes me concerned for
> the day when the format might change. We don't want to _fail_ an upgrade
> because some of the combinations were in the wrong order.

That's fair.  The planner costing code pulling the stats numbers based
on the attributes was smart enough to not care much about the ordering
as far as I recall, but I'd rather make sure of that first.  This
needs some careful lookup.

>> These don't make sense anyway because they have a predictible and
>> perfectly matching correlation relationship.
>>
>=20
> They do, for now, but are we willing to lock ourselves into that forever?

Perhaps not.  I cannot say for sure what's the future is going to be
made of.

> Looking over those functions, they both could have use the same generator,
> but the dependencies-side decided that dependency order doesn't matter,
> which puts doubt in my head that the order is perfectly the same for both,
> so we'd better follow each individually IF we want to enforce order.

I'd try to look at the bits related to pg_dependencies and
pg_ndistinct as two separate concepts, at the end.  They're sort of
alike, but have too many differences already.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmkb6UUACgkQnvQgOdby
QH3gaA/9F/zv9LBxiwcJ0AZ7Ler27z/DkJgBjVi8JBJu6vljeV+R6JiI6m8joE/j
FnoKeENdrZ0+93EGmV9TZn/8Z2RWDoFsQMLcZRdt4mG8WvDHZcML8x+k+xL50/Eu
eII/IXERnBQw+JhNmozCNF8rAPtOmUt0rkQAqQSEcE9/8koHozG13Vx+w/bUde33
kKevn+n3AoqaUJ3NooVY1I6zY6knrKWA4FIOiAtQgKJuPBdkOxYsdIPja5MmUdC1
zIxQryj7Mei8hbNI5sOwMaakhfzUgJEUnHhNJHxliL9XG4zks+B9FZoYu+5kpiE1
1rGQFdN5xDZHtojKVfog34+V73xksNfBLVeUn4KaVLYlf06a3T/VzC6XZPTxl1fn
Ve/dJfIrua4QNYZdENE88Kyqg6KV6uTtv4Z0rk2TeWr+8TZcD3CR4jcIX3N+cOJD
Za8XRWjjSJpY2LeBGloe4RAsIeCVf49i6sG7GLu6yKIoBlKGm5n8oX5vPoZmWoQy
c0+RvHeS/Dm6mroilIdUZ62GRsPDTAbIpC45tCj2ak9Mer9pxbeZAglwCGp9f6LD
LFB8EmSAEJYCCopiF3Jb3y+M6BJRR/qZplzBRXDRje6S2TQJz6VGgVpGIiqdQ4IC
BjwvI0jBb32l0EXcKpV337ASJg2mYWb3hOkSMpW2Y2Yc/cQi2OA=
=UppY
-----END PGP SIGNATURE-----

--exmKyYFTA1M18xbe--