Re: Statistics Import and Export
| От | Corey Huinker |
|---|---|
| Тема | Re: Statistics Import and Export |
| Дата | |
| Msg-id | CADkLM=doAYLmDCv_q0WgRgAjf3gCNzVfvk3f4wWTsZV6sO+QRg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Statistics Import and Export (Corey Huinker <corey.huinker@gmail.com>) |
| Ответы |
Re: Statistics Import and Export
|
| Список | pgsql-hackers |
On Mon, Feb 24, 2025 at 4:30 PM Corey Huinker <corey.huinker@gmail.com> wrote:
After a bit of playing around, it seemed messy to make it into
a join, but we could replace the two array_agg sub-selects with
a single one:
(SELECT pg_catalog.array_agg(ROW(attname, attstattarget) ORDER BY attnum)
FROM pg_catalog.pg_attribute WHERE attrelid = i.indexrelid)
and then what we need could be pulled out of that, although
I'm not sure if pg_dump has logic at hand for deconstructing an
array of composite.
Digging some more on this, I see that we populate indxinfo[j].indkey as if it's an array of Oids, but it's an array of AttrNumber/int2. Shouldn't have caused any problems given that we're dealing with small integers, but it didn't help discoverability just now. Is there some history there that I'm not aware of?
В списке pgsql-hackers по дате отправления: