Re: Bitmap index - first look

>> Additional heap contains unique values and page's number with offset 
>> number in bitmap index, b-tree index contains tuples with the same values 
>> and ItemPointer to heap's row. So, heap is an unnecessary step - b-tree 
>> index should store ItemPointer to the bitmap index directly.
> B-tree points to LOVItem (heap's row) because the LOVItem contains
> some vector metadata, plus the last two words of the actual bitmap
> vector, last_compword and last_word; they are stored there because
> they will be changing in most cases.


I'm talking about pg_bitmapindex.pg_bm_OID tables - they contain distinct values 
from indexed table and pair of (blockNumber, offsetNumber), which is exactly 
ItemPointerData. I suppose, that pair points somewhere in bitmap index. In other 
hand, tuple of index 'pg_bitmapindex.pg_bm_OID_idx' contains the same distinct 
values and ItemPointer pointed to row in corresponding pg_bitmapindex.pg_bm_OID 
table.

Why doesn't ItemPointer in pg_bitmapindex.pg_bm_OID_idx point into bitmap index 
file?

Actually, you don't need a pg_bitmapindex.pg_bm_OID tables at all - the same 
data could be stored in pg_bitmapindex.pg_bm_OID_idx itself. But this is not a 
strong objection, just an a optimization.

BTW, see comments near index_getnext(): * Note: caller must check scan->xs_recheck, and perform rechecking of the *
scankeys if required.  We do not do that here because we don't have * enough information to do it efficiently in the
generalcase.
 

Although it's not true for b-tree now, but it may change.



-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/