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
|
Список | 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 по дате отправления: