Request a Demo
Home   >   mailing lists

Re: Extended Statistics set/restore/clear functions. - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Extended Statistics set/restore/clear functions.
Date
Msg-id CADkLM=czQ0UUyBn3AiHZfJJWRwXH5e2xn056yG0mpuXpW09RSw@mail.gmail.com
Whole thread Raw
In response to Re: Extended Statistics set/restore/clear functions.  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Tree view
> 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.
 
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: GUC thread-safety approaches
Next
From: Viktor Holmberg
Date:
Subject: Re: Running a single test