Re: Statistics Import and Export

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Statistics Import and Export
Дата
Msg-id 473884.1711820380@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Statistics Import and Export  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Statistics Import and Export  (Jeff Davis <pgsql@j-davis.com>)
Re: Statistics Import and Export  (Corey Huinker <corey.huinker@gmail.com>)
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Sat, 2024-03-30 at 13:18 -0400, Tom Lane wrote:
>> Surely they are data, not schema.  It would make zero sense to
>> restore them if you aren't restoring the data they describe.

> The complexity is that pg_upgrade does create the data, but relies on a
> schema-only dump. So we'd need to at least account for that somehow,
> either with a separate stats-only dump, or make a special case in
> binary upgrade mode that dumps schema+stats (and resolves the CREATE
> INDEX issue).

Ah, good point.  But binary-upgrade mode is special in tons of ways
already.  I don't see a big problem with allowing it to dump stats
even though --schema-only would normally imply not doing that.

(You could also imagine an explicit positive --stats switch that would
override --schema-only, but I don't see that it's worth the trouble.)

>> Maybe we need to revisit CREATE INDEX's behavior rather
>> than assuming it's graven in stone?

> Would there be a significant cost to just not doing that? Or are you
> suggesting that we special-case the behavior, or turn it off during
> restore with a GUC?

I didn't have any specific proposal in mind, was just trying to think
outside the box.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Statistics Import and Export
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add pg_basetype() function to obtain a DOMAIN base type