On Wed, Nov 18, 2015 at 12:56 AM, Thom Brown <t...@linux.com> wrote: > On 17 November 2015 at 15:43, Jim Nasby <jim.na...@bluetreble.com> wrote: >> On 11/17/15 4:41 AM, Thom Brown wrote: >>> >>> Could someone post a TL;DR summary of what the current plan looks >>> like? I can see there is a huge amount of discussion to trawl back >>> through. I can see it's something to do with the visibility map. And >>> does it avoid freezing very large tables like the title originally >>> sought? >> >> >> Basically, it follows the same pattern that all-visible bits do, except >> instead of indicating a page is all-visible, the bit shows that all tuples >> on the page are frozen. That allows a scan_all vacuum to skip those pages. > > So the visibility map is being repurposed?
My proposal is to add additional one bit that indicates all tuples on page are completely frozen, into visibility map. That is, the visibility map will become a bitmap with two bits (all-visible, all-frozen) per page. > And if a row on a frozen > page is modified, what happens to the visibility of all other rows on > that page, as the bit will be set back to 0? In this case, the corresponding VM both bits are cleared. Such behaviour is almost same as what postgresql is doing today. 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
