On Thu, Aug 4, 2016 at 01:16:20AM +0100, Simon Riggs wrote: > On 4 August 2016 at 00:56, Bruce Momjian <br...@momjian.us> wrote: > > On Wed, Aug 3, 2016 at 07:28:52PM -0400, Bruce Momjian wrote: > >> With LITE, you can avoid the creation of duplicate-value index entries > >> for indexes without changed column values by using a bitmap in place of > >> the tid item number (16 bits). It can't remove dead tids. > > > > How would you handle the case where there are two LITE index entries > > pointing to two different update chains on the same page? > > When you > > search the page for the first heap chain, could the second index entry > > find the same chain. How would you know which index entry is which > > chain? > > It's easiest to understand this is by imagining each LITE pointer > pointing to a whole page. The chains aren't followed during the scan, > individual heap tuple versions are treated as they would be by a seq > scan. > > That is more expensive than we might like, so the bitmap/linepointer > thing is just an extra tweak to avoid scanning the whole block. The > bitmap refers to ranges of linepointers, not chains. i.e. 0-15, 16-31, > 32-47 etc
Well, there is no way to know how many linepointers there are on a page, so doing "mod 16" automatically hashes the line pointers into the 16-bit field. > > 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. OK. -- 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
