Feedback-ID: i0fe9450f:Fastmail
Date: Sat, 8 Nov 2025 07:56:48 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Tomas Vondra <tomas@vondra.me>, 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: <aQ55MDBjbO8_0fnv@paquier.xyz>
References: 
 <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>
 <CADkLM=cTVN3g7OzdSXfnBHEYNVQiGMJ8cdx1v=zJa86w1A9ULA@mail.gmail.com>
 <aQxb0rHuckPSBeLO@paquier.xyz>
 <CADkLM=dMSJ5pHQoRxj9qoU49s+f33kXbhvm_12g=ARaXgysg=g@mail.gmail.com>
 <aQ2k8--a0FfwSwX9@paquier.xyz>
 <CADkLM=dWQ3r48eAP8NggLqe90_16JKbit9iu9AtuUrZ8+A=qBA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="LOl6phV8B9YeVnZK"
Content-Disposition: inline
In-Reply-To: 
 <CADkLM=dWQ3r48eAP8NggLqe90_16JKbit9iu9AtuUrZ8+A=qBA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aQ55MDBjbO8_0fnv%40paquier.xyz>
Precedence: bulk


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

On Fri, Nov 07, 2025 at 05:28:50PM -0500, Corey Huinker wrote:
> I'm open to other formats, but aside from renaming the json keys (maybe
> "attnums" or "keys" instead of "attributes"?), I'm not sure what really
> could be done and still be JSON. I suppose we could go with a tuple format
> like this:
>=20
> '{({3,4},11),...}' for pg_ndistinct and
> '{({3},4,1.00000),...}'  for pg_dependencies.
>=20
> Those would certainly be more compact, but makes for a hard read by human=
s,
> and while the JSON code is big, it's also proven in other parts of the
> codebase, hence less risky.

I've liked the human-readability factor of the format in the current
patches with names in the keys, and values assigned to each property.

Another thing that may be worth doing is pushing the names of the keys
and some its the JSON meta-data shaping the object into a new header
than can be loaded by both the backend and the frontend.  It would be
nice to not hardcode this knowledge in a bunch of places if we finish
by renaming these attributes.

> A part of me thinks that everything that remains after removing
> in/out/send/recv is just taking a table sample data structure and crunchi=
ng
> numbers to come up with the deserialized data structure...that's in/out
> with a different starting/ending points.
>=20
> There's no denying that JSON parsing is a very different code style than
> statistical number crunching, and mixing the two is incongruous, so it's
> worth a shot, and I'll try that for v9.

Yeah, right.  Thanks.  The parsing pieces seem like pieces worth their
own file.

> The functions in question are needed because the exprs value is itself an
> array of partly-filled-out pg_attribute tuples, so it's common to those t=
wo
> needs, but specific to stats about attributes. Maybe we need an
> attr_stats_utils.h?

Hmm, maybe.  I'd be OK to revisit these structures once we're happy
with the in/out structures.  That would be a good start point before
working on the SQL functions and the dump/restore bits in more
details.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmkOeTAACgkQnvQgOdby
QH3o3A/9EQOUw4bt3mIfg6xWNp+/cVhRPj5krB08dP/RcN4fmO3/eLZH6/ezZpKT
uwn02Bbad1Q+3owB12I2huZ7Zwt4yj0dwx6PbwZYlMk+R3ih6TGhZyZw6P47Rbw7
xVggfy2uCbdqiB10//DMvzOML+P5sgRlaCH+FtIDxU9vQHScQHsh0/93Z4ZBRS/S
IITfQ8pDPN61cCDLeliXv2J1I+QZDcUFKz5fSKziFZVnWaFf18h+t3U48aP4NNmb
+YNPPr1PVC2wMlXj4Al43uxawWbUbaT9j/EXZWdGs2LsC33Nb8khXUNaUCC0qB6n
ngFDQhbhU0yih92PsXi6E70VVAExDRb5fgo4XELeLGc8jLT/vnBz6+FhTXuN5+/a
S0mVGE7U2RLyTe3vREQgld16HVfkHInp7ca+JR24n0WKJTd++AgzlI+Pv4wTClHG
kbjo3Mco3DirhNVBx6LgArvXsuu1QCgT1ij2vXvoVMzHMMHoF2Cpzrs8Gu/nGifX
G1LbXspS1bylhPvVsU1KVCvJ9bDY6mSiFaLqk1hzTBT0NVNa68wYbK1TXpidfrLh
a32JiKJwllNbdLhNpbz7kcZtWRwT9osrQDmevIjSXYKbDmBF0RFlVfngFXYepjOv
Ua6mfdCIPp4+5Zq3ZK/fW4QLfoJqZa2Ap5PAnreiTDhADAMpT8U=
=4uIo
-----END PGP SIGNATURE-----

--LOl6phV8B9YeVnZK--