On Fri, Nov 07, 2008 at 03:56:25PM +0300, Teodor Sigaev wrote:
> After looking at additional heap and b-tree index placed in
> pg_bitmapindex namespace...
>
> Additional heap contains unique values and page's number with offset
> number in bitmap index, b-tree index contains tuples with the same
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 LO
Could you please put more comments on the index build procedure?
I guess it strongly relies on the fact the block number increases as tuples
are returned from "heap scan", doesn't it? However, thanks to synchronized
scans the order of tuples could be a little bit different.
I found no evidence of
After looking at additional heap and b-tree index placed in pg_bitmapindex
namespace...
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
One more point on pg_am: amsearchnull is equal to "f" however the index
stores and could find nulls perfectly.
Regards,
Vladimir Sitnikov
