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

Hi!
>
> At the moment, I'm not sure that the constant is the right number
> for applying transformations, so I'm in search of it, to be
> honest. I will post my observations on this issue later. If you
> don't mind, I'll leave the constant equal to 15 for now.
>
> It's hard to predict. Perhaps accounting for time on each benchmark
> could help decide.
>
I will try to test on JOB [1] (because queries are difficult for the
optimizer due to the significant number of joins and correlations
contained in the dataset) and
tpcds [2] (the benchmark I noticed contains a sufficient number of
queries with "or" expressions).

> Sorry, I don't understand well enough what is meant by points
> "Eliminate unnecessary variables" and "Eliminate unnecessary
> expressions". Can you explain in more detail?
>
> One example is array_type.
> As you can see in v2 and v3 it no longer exists.
>
I get it. Honestly, I was guided by the example of converting "IN" to
"ANY" (transformAExprIn), at least the part of the code when we
specifically convert the expression to ScalarArrayOpExpr.

Both there and here, we first look for a common type for the collected
constants, and if there is one, then we try to find the type for the
array structure.

Only I think in my current patch it is also worth returning to the
original version in this place, since if it is not found, the
ScalarArrayOpExpr generation function will be processed incorrectly and
the request may not be executed at all, referring to the error that it
is impossible to determine the type of node (ERROR: unrecognized node
type. )

At the same time we are trying to do this transformation for each group.
The group here implies that these are combined "or" expressions on the
common left side, and at the same time we consider
only expressions that contain a constant and only equality.

What else should be taken into account is that we are trying to do this
processing before forming a BoolExpr expression (if you notice, then
after any outcome we call the makeBoolExpr function,
which just forms the "Or" expression, as in the original version,
regardless of what type of expressions it combines.

>
> As I said earlier, these are just suggestions.
> But thinking about it now, I think they can be classified as bad early
> optimizations.
Thank you again for your interest in this problem and help. Yes, I think
so too)

1. https://github.com/gregrahn/join-order-benchmark

2.
https://github.com/Alena0704/s64da-benchmark-toolkit/tree/master/benchmarks/tpcds

--
Regards,
Alena Rybakina
Postgres Professional