On Fri, Feb 24, 2017 at 4:06 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: >> Wow, OK. In my view, that makes the chain conversion code pretty much >> essential, because if you had WARM without chain conversion then the >> visibility map gets more or less irrevocably less effective over time, >> which sounds terrible. > > Yes. I decided to complete chain conversion patch when I realised that IOS > will otherwise become completely useful if large percentage of rows are > updated just once. So I agree. It's not an optional patch and should get in > with the main WARM patch.
Right, and it's not just index-only scans. VACUUM gets permanently more expensive, too, which is probably a much worse problem. >> But it sounds to me like even with the chain >> conversion, it might take multiple vacuum passes before all visibility >> map bits are set, which isn't such a great property (thus e.g. >> fdf9e21196a6f58c6021c967dc5776a16190f295). > > The chain conversion algorithm first converts the chains during vacuum and > then checks if the page can be set all-visible. So I'm not sure why it would > take multiple vacuums before a page is set all-visible. The commit you quote > was written to ensure that we make another attempt to set the page > all-visible after al dead tuples are removed from the page. Similarly, we > will convert all WARM chains to HOT chains and then check for all-visibility > of the page. OK, that sounds good. And there are no bugs, right? :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
