On Mon, Jul 13, 2015 at 9:22 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-07-13 21:03:07 +0900, Sawada Masahiko wrote: >> 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. > > Why would it? Sure, you can only set allvisible and not the frozen bit, > but that's fine. That way the cost for freezing can be paid over time. > > If we require terrabytes of data to be scanned, including possibly > rewriting large portions due to freezing, before index only scans work > and most vacuums act in a partial manner the migration to 9.6 will be a > major pain for our users.
Ah, If we set all bit as not all-frozen, we don't need to whole table scanning, only scan vm. And I agree with this. But please image the case where old cluster has table which is very large, read-only and vacuum freeze is done. In this case, the all-frozen bit of such table in new cluster will not set, unless we do vacuum freeze again. The information of all-frozen of such table is lacked. 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
