Re: Speeding up pg_upgrade - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Speeding up pg_upgrade
Date
Msg-id 20171209010228.GA12936@momjian.us
Whole thread Raw
In response to Re: Speeding up pg_upgrade  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Speeding up pg_upgrade  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Fri, Dec  8, 2017 at 12:26:55PM -0500, Stephen Frost wrote:
> Bruce,
> 
> * Bruce Momjian (bruce@momjian.us) wrote:
> > I think the big problem with two-stage pg_upgrade is that the user steps
> > are more complex, so what percentage of users are going use the
> > two-stage method.  The bad news is that only a small percentage of users
> > who will benefit from it will use it, and some who will not benefit it
> > will use it.  Also, this is going to require significant server changes,
> > which have to be maintained.
> 
> This is where I think we need to be considering a higher-level tool that
> makes it easier to run pg_upgrade and which could handle these multiple
> stages.
> 
> > I think we need some statistics on how many users are going to benefit
> > from this, and how are users suppose to figure out if they will benefit
> > from it?
> 
> If the complexity issue is addressed, then wouldn't all users who use
> pg_upgrade in link mode benefit from this..?  Or are you thinking we

The instructions in the docs are going to be more complex.  We don't
have any planned way to make the two-stage approach the same complexity
as the single-stage approach.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pgsql: Prohibit identity columns on typed tables and partitions
Next
From: Michael Paquier
Date:
Subject: Re: proposal: alternative psql commands quit and exit