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
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
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
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
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
1) Sometimes index doesn't find all matching rows:
postgres=# SELECT * FROM qq WHERE t ='asd';
i | t
---+-
2 | asd
1 | asd
2 | asd
(3 rows)
postgres=# SET enable_seqscan=off;
SET
postgres=# SELECT * FROM qq WHERE t ='asd';
i |
One more point on pg_am: amsearchnull is equal to f however the index
stores and could find nulls perfectly.
Regards,
Vladimir Sitnikov
