On Mon, Jul 13, 2015 at 9:03 PM, Sawada Masahiko <sawada.m...@gmail.com> wrote: > On Mon, Jul 13, 2015 at 7:46 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Mon, Jul 13, 2015 at 3:39 PM, Sawada Masahiko <sawada.m...@gmail.com> >> wrote: >>> >>> On Tue, Jul 7, 2015 at 9:07 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> > On 6 July 2015 at 17:28, Simon Riggs <si...@2ndquadrant.com> wrote: >>> > >>> >> I think we need something for pg_upgrade to rewrite existing VMs. >>> >> Otherwise a large read only database would suddenly require a massive >>> >> revacuum after upgrade, which seems bad. That can wait for now until we >>> >> all >>> >> agree this patch is sound. >>> > >>> > >>> > Since we need to rewrite the "vm" map, I think we should call the new >>> > map >>> > "vfm" >>> > >>> > That way we will be able to easily check whether the rewrite has been >>> > conducted on all relations. >>> > >>> > Since the maps are just bits there is no other way to tell that a map >>> > has >>> > been rewritten >>> >>> To avoid revacuum after upgrade, you meant that we need to rewrite >>> each bit of vm to corresponding bits of vfm, if it's from >>> not-supporting vfm version(i.g., 9.5 or earlier ). right? >>> If so, we will need to do whole scanning table, which is expensive as >>> well. >>> Clearing vm and do revacuum would be nice, rather than doing in >>> upgrading, I think. >>> >> >> How will you ensure to have revacuum for all the tables after >> upgrading? > > We use script file which are generated by pg_upgrade.
I haven't followed this thread closely, but I am sure you recall that vacuumdb has a parallel mode. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
