Re: Speeding up pg_upgrade

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Speeding up pg_upgrade
Date: 2017-12-09 01:02:28
Message-ID: 20171209010228.GA12936@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 8, 2017 at 12:26:55PM -0500, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (bruce(at)momjian(dot)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(at)momjian(dot)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 +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-12-09 04:03:18 Re: proposal: alternative psql commands quit and exit
Previous Message Michael Paquier 2017-12-08 23:43:21 Re: pgsql: Prohibit identity columns on typed tables and partitions