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
* scan keys if required. We do not do that here because we don't have
* enough information to do it efficiently in the general case.
Although it's not true for b-tree now, but it may change.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
