From: Vasilis Ventirozos <v.ventirozos@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: postgresql9.4 aws - no pg_upgrade
Date: Thu, 2 Nov 2017 23:27:10 +0200
References: 
 <CANcY5AxSwhtFFfUMCKpv-6sWHzzmd4c+jYJvT=4JadHwuTLkfA@mail.gmail.com>
 <5c0dd3a9-bee1-13ce-04aa-18571b12e5c4@commandprompt.com>
 <CANcY5Ax=sd4L4d8+8KTiv3fAac3NaykMaemj7iaetiMbRtRqhg@mail.gmail.com>
 <CANcY5AxRDqUGvrgcPJnMjxxpRETrzibEyci+9o0A2t-eAhmJew@mail.gmail.com>
 <69c5d778-5d85-dc2e-c70f-5ef95b06db4f@commandprompt.com>
 <CANcY5Az=uXeXY+UAb49bGrz-cAr9g-5kE5+eq6bPUp-0f7H47g@mail.gmail.com>
 <84769c92-3364-1b03-3217-56716e3e9fff@commandprompt.com>
 <CANcY5AxTULKWfqdw=M54sHORgQMj6ZKPNdCYLwyg8+tS=xNrVg@mail.gmail.com>
 <a5deffe9-a6f5-736d-14de-044f75d94edb@commandprompt.com>
 <CANcY5Aw_T6Aqkq3Jbod=NxKGVtuawTUYGbuw9qGChzXp0QNfJg@mail.gmail.com>
 <CANcY5AyeiPnEkcC7PgoFNQMuwidrBNkNHcXVJivTKT4_Lia7hw@mail.gmail.com>
 <CANcY5AyOVvGOJX48W+s5LqkQW+knyvCafGYZXPrCeK0j-AQZFg@mail.gmail.com>
 <CANcY5AwMvaYfwOgx=QtH-vRn=kc66W+ww7bb=uCCQGgvA0DB6w@mail.gmail.com>
To: pgsql-admin <pgsql-admin@postgresql.org>
In-Reply-To: 
 <CANcY5AwMvaYfwOgx=QtH-vRn=kc66W+ww7bb=uCCQGgvA0DB6w@mail.gmail.com>
Message-Id: <F96FA87E-9234-4788-9B5D-FA3159FED7D4@gmail.com>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org


> On 2 Nov 2017, at 23:03, bala jayaram <balajayaram22@gmail.com> wrote:
>=20
> Hi Team,
>=20
>=20
> We tried in production, pg_upgrade works well. But running vacuumdb , res=
ulted in huge spike in CPU, system halted. Is there a way to fasten or para=
llel vacuum solution for faster recovery after pg_upgrade.
>=20
> Our database size is around 500GB, contains multiple databases, huge reco=
rds. What is the minimum way to do a vacuuming after pg_upgrade? This is fo=
r migration from 9.3 to 9.4.

All you need to do right after the upgrade is getting new statistics by run=
ning "analyze" or by doing something like vacuumdb -a -v -z.
That should take a while but it shouldn't "halt" anything. I believe that 9=
.4 doesn't have -j in vacuumdb, so you can script
something that will will get all tables, split them and run each part in X =
number of psqls.
When you are done with the statistics then scheduling a vacuum would be a g=
ood idea. this can be done during any convenient=20
time or you can just split the work using a script.

Regards,
Vasilis Ventirozos

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin