Re: Extended Statistics set/restore/clear functions.
| От | Corey Huinker |
|---|---|
| Тема | Re: Extended Statistics set/restore/clear functions. |
| Дата | |
| Msg-id | CADkLM=d2pSA+9RqELkYSijBhJrnS2xpt0rmMEq70C5a+7kpBQw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Extended Statistics set/restore/clear functions. (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Extended Statistics set/restore/clear functions.
|
| Список | pgsql-hackers |
It seems to me that this comes down to the text[] representation when
we read this data from the catalogs, where we can just rely on NULL
being in the value, and the official marker in this case:
https://www.postgresql.org/docs/current/arrays.html#ARRAYS-INPUT
And we're doing a lot of casting ANYARRAY to text throughout this and the attribute stats, so that our assurance that we can live without nulls.
Perhaps we have a couple of specific cases where checking for we want
some NULL-ness knowledge? It would be less expensive than a full
array deconstruction, for sure, especially if the MCVs are large text
values.
It's a good theory, or maybe the original coder just assumed that the caller of pg_mcv_list() SRF could lateral-unnest the output and keep only the interesting columns.
Rebasing and null-rip-out underway.
В списке pgsql-hackers по дате отправления: