Re: Extended Statistics set/restore/clear functions.

Corey Huinker <corey.huinker@gmail.com>

From: Corey Huinker <corey.huinker@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: jian he <jian.universality@gmail.com>, Tomas Vondra <tomas@vondra.me>, pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Date: 2025-11-18T08:52:31Z
Lists: pgsql-hackers

Attachments

>
> > SELECT '[{"attributes" : [2,3], "ndistinct" : 4, "ndistinct" :
> > 14}]'::pg_ndistinct;
> >                pg_ndistinct
> > -------------------------------------------
> >  [{"attributes": [2, 3], "ndistinct": 14}]
> >
> > SELECT '[{"attributes" : [2,3], "ndistinct" : 4, "attributes" :
> > []}]'::pg_ndistinct;
> >                pg_ndistinct
> > ------------------------------------------
> >  [{"attributes": [2, 3], "ndistinct": 4}]
> >
> > Is the above output what we expected?
>
> Interesting one.  The extra "attributes" should not be required once
> we have one set, indeed.
> --
> Michael
>

v15:

- catches duplicate object keys cited above
- enforces attnum ordering (ascending positive numbers followed by
descending negative numbers, no zeros allowed), which means we get
duplicate attnum detection for free
- attnum validation is now done as soon as the attnum is parsed
- tests refactored to put attnums in proper order
- unfortunately, this means that one of the error cases from
stats_import.sql (attnum = 0) is now an error rather than something that
can be soft-excluded.
- didn't enforce combinatorical completeness for dependencies because not
all combinations are guaranteed to be there.
- didn't enforce combinatorical completeness for ndistinct because I'm not
convinced we should.