Re: Statistics Import and Export
| От | Tom Lane |
|---|---|
| Тема | Re: Statistics Import and Export |
| Дата | |
| Msg-id | 1480048.1740432322@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Statistics Import and Export (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Statistics Import and Export
|
| Список | pgsql-hackers |
I wrote:
> Hmm ... I was thinking we had it already for ALTER INDEX SET
> STATISTICS, but I see that is depending on some quite ad-hoc
> code (look for indstatcols and indstatvals in pg_dump.c).
> I wonder if we could generalize that a bit and share the
> work with this case. Those array_agg calls don't look too fast
> anyway, would be better if we could rewrite as a join I bet.
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. Or we could leave it as two array_aggs,
aggregating attname and attstattarget separately but removing
the attstattarget filter.
regards, tom lane
В списке pgsql-hackers по дате отправления: