I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> 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
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm, the ~~ condition should get treated as a "filter" not a "recheck".
>> I suppose I broke this somewhere ...
> I started to look at this last night. The culprit seems to be this patch:
Yeah, it appears that I oversimplified ma
Tom Lane wrote:
"Rushabh Lathia" <[EMAIL PROTECTED]> writes:
Simple select give wrong result when it uses the Bitmap Heap Scan path.
It's generally appropriate to mention which PG version you're working
with when you report a bug.
postgres=# explain select proname from pg_proc where proname
Tom Lane wrote:
"Rushabh Lathia" <[EMAIL PROTECTED]> writes:
Simple select give wrong result when it uses the Bitmap Heap Scan path.
It's generally appropriate to mention which PG version you're working
with when you report a bug.
I was on 8.4 CVS Head, Next time will sure take car
"Rushabh Lathia" <[EMAIL PROTECTED]> writes:
> Simple select give wrong result when it uses the Bitmap Heap Scan path.
It's generally appropriate to mention which PG version you're working
with when you report a bug.
> postgres=# explain select proname from pg_proc where proname like 'my_pro1';
>
Analysis:
While debugging bitmap heap scan (BitmapHeapNext function) found that first
we perform the underlying index scan and then iterate over bitmap. Now while
iterating, we execute ExecQual only if tbmres->recheck is true. And for the
query tbmres->recheck is false.
But from the que
Simple select give wrong result when it uses the Bitmap Heap Scan path.
postgres=# CREATE OR REPLACE FUNCTION my_exec_im_test_func(i integer)
RETURNS integer AS $$
BEGIN
RETURN i + 1;
END;
$$ LANGUAGE plpgsql;
CREATE FUNCTION
postgres=# set enable_seqscan=off;
SET
