On Thu, Dec 7, 2017 at 11:28 AM, Justin Pryzby wrote:
> On Tue, Dec 05, 2017 at 09:01:35AM -0500, Bruce Momjian wrote:
> > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > zero-downtime upgrades. ... we discussed speeding up pg_upgrade.
> >
> > There are clusters that
On Sat, Dec 9, 2017 at 08:45:14AM -0500, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Dec 8, 2017 at 12:26:55PM -0500, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > I think the big problem with two-stage pg_upgrade is that
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Dec 8, 2017 at 12:26:55PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@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 goi
On Fri, Dec 8, 2017 at 12:26:55PM -0500, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@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
Bruce,
* Bruce Momjian (br...@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 u
> On Dec 8, 2017, at 9:21 AM, Stephen Frost wrote:
>
> Mark,
>
> * Mark Dilger (hornschnor...@gmail.com) wrote:
>>> On Dec 7, 2017, at 10:24 PM, Bruce Momjian wrote:
>>> I think the big problem with two-stage pg_upgrade is that the user steps
>>> are more complex, so what percentage of users a
Mark,
* Mark Dilger (hornschnor...@gmail.com) wrote:
> > On Dec 7, 2017, at 10:24 PM, Bruce Momjian 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 o
> On Dec 7, 2017, at 10:24 PM, Bruce Momjian wrote:
>
> On Thu, Dec 7, 2017 at 10:37:30AM -0500, Stephen Frost wrote:
>> Alexander,
>>
>> * Alexander Kukushkin (cyberd...@gmail.com) wrote:
>>> Couple of months ago we at Zalando upgraded a few databases of different
>>> sizes to 9.6.
>>
>> Tha
On Thu, Dec 7, 2017 at 10:37:30AM -0500, Stephen Frost wrote:
> Alexander,
>
> * Alexander Kukushkin (cyberd...@gmail.com) wrote:
> > Couple of months ago we at Zalando upgraded a few databases of different
> > sizes to 9.6.
>
> Thanks for sharing your experience!
>
> > During preparations to t
Tom, David,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > 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
>
On Thu, Dec 7, 2017 at 12:04 PM, Stephen Frost wrote:
> 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
Stephen Frost writes:
> * Tom Lane (t...@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
>> droppe
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > If we go down that route, since this makes a pretty serious difference
> > in terms of what the user has to deal with post-pg_upgrade, I'd suggest
> > we require an additional option for the user to pass when stats aren't
> >
Stephen Frost writes:
> If we go down that route, since this makes a pretty serious difference
> in terms of what the user has to deal with post-pg_upgrade, I'd suggest
> we require an additional option for the user to pass when stats aren't
> going to be migrated, so they are aware of that.
-1 .
Alvaro Herrera writes:
> Tom Lane wrote:
>> 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 considera
Tom Lane wrote:
> Alvaro Herrera 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?
>
> Th
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Dec 7, 2017 at 11:42 AM, Tom Lane wrote:
> > Alvaro Herrera 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
> >> serializi
On Thu, Dec 7, 2017 at 11:42 AM, Tom Lane wrote:
> Alvaro Herrera 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 l
Alvaro Herrera 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 don
On Tue, Dec 05, 2017 at 09:01:35AM -0500, Bruce Momjian wrote:
> As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> zero-downtime upgrades. ... we discussed speeding up pg_upgrade.
>
> There are clusters that take a long time to dump the schema from the old
> cluster
Mayb
Alvaro,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> Stephen Frost wrote:
> > * Alexander Kukushkin (cyberd...@gmail.com) wrote:
>
> > > 2 ANALYZE phase is a pain. I think everybody agrees with it.
> > >
> > > 2.5 Usually ANALYZE stage 1 completes quite fast and performance becomes
> > >
Stephen Frost wrote:
> Alexander,
> * Alexander Kukushkin (cyberd...@gmail.com) wrote:
> > 2 ANALYZE phase is a pain. I think everybody agrees with it.
> >
> > 2.5 Usually ANALYZE stage 1 completes quite fast and performance becomes
> > reasonable, except one case: some of the columns might have
Alexander,
* Alexander Kukushkin (cyberd...@gmail.com) wrote:
> Couple of months ago we at Zalando upgraded a few databases of different
> sizes to 9.6.
Thanks for sharing your experience!
> During preparations to the I've found 2.5 pain-points:
>
> 1. We are using schema-based api deployment.
Hi,
> Yes, dump/reload of analyze statistics seems like a better use of time.
> I have avoided it since it locks us into supporting the text
> respresentation of data type, but at this point it might be worth it.
>
>
Couple of months ago we at Zalando upgraded a few databases of different
sizes t
On Tue, Dec 5, 2017 at 09:30:53AM -0500, Stephen Frost wrote:
> > > The other concern is if there's changes made to the catalogs by non-DDL
> > > activity that needs to be addressed too (logical replication?); nothing
> > > definite springs to mind off-hand for me, but perhaps others will think
>
On 12/5/17 09:23, Stephen Frost wrote:
> Right, but that doesn't really answer the question as to which part of
> the pg_upgrade process is taking up the time.
Yeah, that should be measured before we do anything.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> > In any case, of course, if we're able to move part of what pg_upgrade
> > does to be while the old server is online then that takes whatever the
> > cost of that is out of the downtime window. The question is if that's a
> > 5% improvement in t
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Dec 5, 2017 at 09:16:02AM -0500, Stephen Frost wrote:
> > > There are clusters that take a long time to dump the schema from the old
> > > cluster and recreate it in the new cluster. One idea of speeding up
> > > pg_upgrade would be to a
On Tue, Dec 5, 2017 at 09:23:49AM -0500, Stephen Frost wrote:
> Dave,
>
> * Dave Page (dp...@pgadmin.org) wrote:
> > On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
> > > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > > zero-downtime upgrades. After the usual
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
> > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > zero-downtime upgrades. After the usual discussion of using logical
> > replication, Slony, and perhaps having the
On Tue, Dec 5, 2017 at 11:16:26PM +0900, Dave Page wrote:
> Hi
>
> On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
>
> As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> zero-downtime upgrades. After the usual discussion of using logical
> replication,
On Tue, Dec 5, 2017 at 09:16:02AM -0500, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > zero-downtime upgrades. After the usual discussion of using logical
> > replication, Slony, and pe
Hi
On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
> As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> zero-downtime upgrades. After the usual discussion of using logical
> replication, Slony, and perhaps having the server be able to read old
> and new system cata
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> zero-downtime upgrades. After the usual discussion of using logical
> replication, Slony, and perhaps having the server be able to read old
> and new system catalogs, we d
34 matches
Mail list logo
