| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Tender Wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Extended Statistics set/restore/clear functions. |
| Date: | 2026-01-28 06:12:17 |
| Message-ID: | CADkLM=d2pSA+9RqELkYSijBhJrnS2xpt0rmMEq70C5a+7kpBQw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-01-28 06:14:32 | ATPrepCmd: cleanup unreachable AT_AddIndexConstraint handling |
| Previous Message | Michael Paquier | 2026-01-28 06:08:17 | Re: Extended Statistics set/restore/clear functions. |