Re: Speeding up pg_upgrade

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Speeding up pg_upgrade
Дата
Msg-id 20171207160413.GD4628@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Speeding up pg_upgrade  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Alvaro,

* Alvaro Herrera (alvherre@alvh.no-ip.org) wrote:
> Stephen Frost wrote:
> > * 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.

Right, I think that's what Bruce was getting at and certainly makes
sense to me as well.  I agree that it's a definite pain point for
people.  One complication is going to be custom data types, of course..

Thanks!

Stephen

Вложения

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Speeding up pg_upgrade
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table,log i