Re: BUG #17618: unnecessary filter column <> text even after adding index - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17618: unnecessary filter column <> text even after adding index
Date
Msg-id 739953.1663701274@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17618: unnecessary filter column <> text even after adding index  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: BUG #17618: unnecessary filter column <> text even after adding index
List pgsql-bugs
Jeff Janes <jeff.janes@gmail.com> writes:
> You are describing a Recheck, but attributing its properties to a Filter.

You're right of course, momentary brain fade on my part.

> I don't know about being a bug, but it is at least a mild mal-feature that
> boolean index columns/expressions can't be dealt with better, and have to
> be handed in a filter rather than in a recheck.

Yeah ... looking at create_bitmap_scan_plan, I see that it does this:

    /*
     * When dealing with special operators, we will at this point have
     * duplicate clauses in qpqual and bitmapqualorig.  We may as well drop
     * 'em from bitmapqualorig, since there's no point in making the tests
     * twice.
     */
    bitmapqualorig = list_difference_ptr(bitmapqualorig, qpqual);

I wonder if that isn't backwards, ie we should prefer to put duplicates
in bitmapqualorig (the recheck condition) instead of qpqual (the filter).
If my head is screwed on correctly today, that should allow us to skip
checking the condition much of the time, and the skip would be safe
if the index is correctly asserting that no recheck is needed.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Jeff Davis
Date:
Subject: Re: PANIC in heap_delete during ALTER TABLE
Next
From: Tom Lane
Date:
Subject: Re: BUG #17618: unnecessary filter column <> text even after adding index