Re: Statistics Import and Export
| От | Corey Huinker |
|---|---|
| Тема | Re: Statistics Import and Export |
| Дата | |
| Msg-id | CADkLM=dfdTtHcN=oR1sHnUzRfms39MthcBMb7D+Soc=HAWq2ZQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Statistics Import and Export (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Statistics Import and Export
|
| Список | pgsql-hackers |
On Mon, Feb 24, 2025 at 2:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Corey Huinker <corey.huinker@gmail.com> writes:
> Sadly, that attnum isn't available in pg_stats, so we'd have to reintroduce
> the joins to pg_namespace and pg_class to get at pg_attribute, at least for
> indexes.
This argument seems to be made still from the mindset that you are
going to form a query that produces exactly what needs to be dumped,
without any additional processing. pg_dump has all that info at
hand; there is no need to re-query the server for it.
I went looking just now, and I can't find it. I see where we have attname and attnum arrays for tables, but not indexes. We keep an array of attnums for the index, but we'd need to add an array of attnames in order to correlate back to our results of pg_stats. If I'm missing something, please correct me, but it seems like all the index stuff we'd get from attributes we instead get from:
"pg_catalog.pg_get_indexdef(i.indexrelid) AS indexdef, "
"pg_catalog.pg_get_indexdef(i.indexrelid) AS indexdef, "
В списке pgsql-hackers по дате отправления: