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 +
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 |