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 по дате отправления: