Re: Bitmap Indexes patch (was Re: Bitmap Indexes: request for feedback)

> I looked at that aspect of the patch specifically a few weeks back while
> checking for possible issues with Hot Standby. IIRC the patch is fairly
> careful with locking and uses Exclusive locks extensively throughout. I
> looked at both the theory and the implementation. Unless Gianni changed
> something in that regard recently, I don't understand that comment at
> all. Probably need to provide specific examples of your concerns.
>
The major thing there is to get the modifications right. There is no much
sense in reviewing "wrong" code against "locking issues".

I wish to focus on the performance aspect of the patch, however, it turned
out there are major issues with functionality: the index stores wrong tids
inside :(
I really would love to fix that issue and have a chance to validate the
performance. Unfortunately, I have spent more than a day with almost void
success.

I have two testcases for which the index fails to get the correct result:

Testcase 1 (I guess there is a conflict between _bitmap_formitem and
mergewords):

Basically I create a table with all the rows equal to 1 besides 19-th, which
is 0.

create table t1 as select case when i=19 then 0 else 1 end as i from
generate_series(1,20) as s(i)
create index t1ix on t1 using bitmap (i) where i = 0;
set enable_seqscan=off;
select ctid,i From t1 where i=0; -- no rows selected. Debug shows index
suggests ctid==(0,35) instead of (0,19). 35==16+16+3.

Testcase 2

create table t2 as select i, 0 j from generate_series(1,1000) as s(i);
update t2 set j=1 where i in (5, 230)
create index t2ix on t2 using bitmap(j) where j=1;

set enable_seqscan=off;
select ctid, i, j from t2 where j=1; -- no rows selected. Debug shows index
suggests ctids==(0,97) and (0,98) instead of (4,97) and (4,98) -- it loses
page number somewhere on the way.

Both testcases reveal defects in index creation.

Regards,
Vladimir Sitnikov