Re: Speeding up pg_upgrade

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Speeding up pg_upgrade
Дата
Msg-id 20171207160232.auayfcnaexuudqy7@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Speeding up pg_upgrade  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Speeding up pg_upgrade  (Stephen Frost <sfrost@snowman.net>)
Re: Speeding up pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Stephen Frost wrote:
> Alexander,

> * Alexander Kukushkin (cyberdemn@gmail.com) wrote:

> > 2 ANALYZE phase is a pain. I think everybody agrees with it.
> > 
> > 2.5 Usually ANALYZE stage 1 completes quite fast and performance becomes
> > reasonable, except one case: some of the columns might have non default
> > statistics target.
> 
> Ok, if the stage-1 is very fast and performance is reasonable enough
> after that then perhaps it's not so bad to keep it as-is for now and
> focus on the dump/restore time.  That said, we should certainly also
> work on improving this too.

It seems pretty clear to me that we should somehow transfer stats from
the old server to the new one.  Shouldn't it just be a matter of
serializing the MCV/histogram/ndistinct values, then have capabilities
to load on the new server?  I suppose it'd just be used during binary
upgrade, but the point seems painful enough for a lot of users.
Obviously it would not be the raw contents of pg_statistic{,_ext}, but
rather something a bit higher-level.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Speeding up pg_upgrade
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Speeding up pg_upgrade