On Wed, Aug 3, 2016 at 08:34:02PM -0400, Bruce Momjian wrote: > On Thu, Aug 4, 2016 at 01:16:20AM +0100, Simon Riggs wrote: > > > Would you only add a LITE index entry when there isn't an > > > existing index entry for the same values and heap page? That seems > > > quite complicated. > > > > The insertion algorithm is described. Doesn't seem complicated to me. > > Ah, I see it now: > > As UPDATEs occur we request inserts into the index. If a lossy index > pointer already exists that covers the new linepointer then we skip > the index insert, optimizing writes to the index. > > I thought you meant "already exists" just means it matches the existing > range. I was unclear that was the entire page.
How do plan to clear the bitmask so it, over time, doesn't end up being all-set? I can see how a non-LITE index tuple would become a LITE tuple when an update chain happens on the same page, but then new matching index values would also set the bitmap, update-chain or not. Then, when the update chain is gone and only non-update-chain tuples exist, you will need to remove the bitmap and create new index entries by scanning the heap page. Also, what happens when you have two non-LITE index tuples in a heap page, and then you create an update chain in the heap page --- do you remove one of the two index entries and create a bitmap out of the remaining one? Do you put them back when the heap chain is gone? Also, why not use this bitmap for all indexes, not just update chains? Because it would break index-only scans? I think there are two use-cases for LITE --- first, it would shrink indexes for tables with many duplicate indexed values on the same page. In the case Simon mentioned, it would help with update chain churn, but the problem is it seems to cause a lot of overhead to create and remove the bitmap in the index. This is why I was thinking of per-update-chain LITE entries. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers