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. > Till the time Vacuum is done on the tables that > have vm before upgrade, any queries on those tables can > become slower. Even If we implement rewriting tool for vm into pg_upgrade, it will take time as much as revacuum because it need whole scanning table. I meant that we rewrite vm using by existing facility (i.g., vacuum (freeze)), instead of implementing new rewriting tool for vm. Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
