Re: Speeding up pg_upgrade - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Speeding up pg_upgrade
Date
Msg-id 20171207183710.3gwzpyg5hermv477@alvherre.pgsql
Whole thread Raw
In response to Re: Speeding up pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Speeding up pg_upgrade
List pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > 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?
> 
> The reason pg_upgrade hasn't done that in the past is not wishing to
> assume that the new version does stats identically to the old version.
> Since we do in fact add stats or change stuff around from time to time,
> that's not a negligible consideration.

Sure, but the new version can probably limp along with incomplete stats
until the next natural ANALYZE runs -- the system is operational in much
shorter time than if you have to make it all wait for the post-upgrade
full-database ANALYZE run.  The serialization step is so that the
underlying representation doesn't have to remain identical -- surely the
new server would be able to represent whatever the old server was able
to, regardless of any improvement made.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: explain analyze output with parallel workers - question aboutmeaning of information for explain.depesz.com
Next
From: Robert Haas
Date:
Subject: Re: pgsql: Support Parallel Append plan nodes.