Re: Speeding up pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Speeding up pg_upgrade
Дата
Msg-id 15532.1512673787@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Speeding up pg_upgrade  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Speeding up pg_upgrade  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Yeah, there's that.  But the rate of change in pg_statistic hasn't been
>> *that* large.  Alvaro might be right that we can design some transmission
>> procedure that allows stats to be forward-migrated when compatible and
>> dropped when not.

> Well, if it's dropped, I think we need to make sure that users are aware
> of that going in and that's why I was suggesting a switch.  If you've
> got a better idea for that, great, but having certain pg_upgrade
> migrations require running ANALYZE and some migrations not require it is
> something we need to make users *very* clear about.  No, I don't think a
> note in the release notes is really enough..

Seems like we could make this reasonably transparent if pg_upgrade
continues to emit an analyze script that you're supposed to run
afterwards.  It just has to vary how much that script does.

            regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: plpgsql test layout
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Speeding up pg_upgrade