On Fri, Feb 24, 2017 at 3:31 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > On Fri, Feb 24, 2017 at 3:23 PM, Robert Haas <robertmh...@gmail.com> wrote: >> I don't immediately see how this will work with index-only scans. If >> the tuple is HOT updated several times, HOT-pruned back to a single >> version, and then the page is all-visible, the index entries are >> guaranteed to agree with the remaining tuple, so it's fine to believe >> the data in the index tuple. But with WARM, that would no longer be >> true, unless you have some trick for that... > > Well the trick is to not allow index-only scans on such pages by not marking > them all-visible. That's why when a tuple is WARM updated, we carry that > information in the subsequent versions even when later updates are HOT > updates. The chain conversion algorithm will handle this by clearing those > bits and thus allowing index-only scans again.
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. 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). -- 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