Re: POC, WIP: OR-clause support for indexes

On 23/8/2024 14:58, Alexander Korotkov wrote:
> On Fri, Aug 23, 2024 at 1:23 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>> The last query doesn't group clauses into two indexes. The reason is in
>> match_index_to_operand which classifies all 'x=' to one class. I'm not
>> sure because of overhead, but it may be resolved by using
>> predicate_implied_by to partial indexes.
>
> Yes, this is the conscious limitation of my patch: to consider similar
> OR arguments altogether and one-by-one, not in arbitrary groups. The
> important thing here is that we still generating BitmapOR patch as we
> do without the patch. So, there is no regression. I would leave this
> as is to not make this feature too complicated. This could be improved
> in future though.
It looks reasonable for me, thanks for the explanation.

What's more, I suspicious about the line:
*subrinfo = *rinfo;

Here, you copy everything, including cached estimations like norm_selec
or eval_cost. I see that the match_orclause_to_indexcol creates a new
SAOP where all caches will be cleaned, but just to be sure, maybe we
should reset any cached estimations to default values — in that case,
anyone who tries to build a new path based on these grouped OR clauses
will recalculate that data.
At least, incorrect eval_cost of iclause->rinfo can slightly change the
cost of rechecking operation, can't it?

--
regards, Andrei Lepikhov