Re: Problem with Bitmap Heap Scan

I wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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