Re: BUG #17618: unnecessary filter column <> text even after adding index

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17618: unnecessary filter column <> text even after adding index
Дата
Msg-id 739953.1663701274@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17618: unnecessary filter column <> text even after adding index  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: BUG #17618: unnecessary filter column <> text even after adding index  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: PANIC in heap_delete during ALTER TABLE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17618: unnecessary filter column <> text even after adding index