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 care
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
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 matters in
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 too
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;
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
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';
