>> 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/