Re: Speeding up pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Speeding up pg_upgrade
Date
Msg-id 15532.1512673787@sss.pgh.pa.us
Whole thread Raw
In response to Re: Speeding up pg_upgrade  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Speeding up pg_upgrade
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: plpgsql test layout
Next
From: "David G. Johnston"
Date:
Subject: Re: Speeding up pg_upgrade