Re: Problem with Bitmap Heap Scan

I wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Attached is a patch that changes create_bitmap_subplan so that the 
>> condition put into Recheck condition is never stronger than the 
>> condition automatically handled by the index. Does that look right to you?

> I think this is still too simplistic, but will look closer.  One point
> is that it's not accounting for the bitmap AND/OR structure that might
> be above the individual indexscans.  The original coding avoided that
> problem by making all the decisions at the top level, and I'm inclined
> to stick with that approach.

I've fixed this by reverting create_bitmap_subplan to its previous
behavior with two output lists.  The scheme you suggested is a bit
logically cleaner, but aside from the issue of AND/OR conditions it
has one unpleasant feature: the RECHECK condition would get copies of
derived clauses.  For instance "col LIKE 'foo%'" would end up with
a plan like
Recheck: col >= 'foo' AND col < 'fop'Filter: col ~~ 'foo%'    Index Cond: col >= 'foo' AND col < 'fop'

The tests in create_bitmap_scan_plan aren't smart enough to recognize
that the recheck conditions are redundant given the filter condition.

The former and now-restored behavior avoids this problem, though it has
the assumption that every indexclause condition came from scan_clauses
(or has been put into bitmapqualorig in the join case), else it might
fail to enforce special operators.  That's certainly true at the moment
though it seems a bit ugly to assume it here.  It might be a good idea
to try to refactor the representation of special/derived quals to make
this stuff a bit more straightforward.  I don't care to tackle that now
though.
        regards, tom lane