Re: execExprInterp() questions / How to improve scalar array op expr eval?

Hi,

On 2020-04-12 08:55:44 -0400, James Coleman wrote:
> On Sat, Apr 11, 2020 at 5:32 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2020-04-11 15:53:11 -0400, James Coleman wrote:
> > > On Sat, Apr 11, 2020 at 2:01 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > > - If not, is there a way in that framework to know if the array expr
> > > > > has stayed the same through multiple evaluations of the expression
> > > > > tree (i.e., so you could expand and sort it just once)?

> > > Ok. Seems like it'd be likely to be interesting (maybe in other places
> > > too?) to know if:
> > > - Something is actually a param that can change, and,
> > > - When (perhaps by some kind of flag or counter) it has changed.
> >
> > We do have the param logic inside the executor, which does signal which
> > params have changed. It's just independent of expression evaluation.
> >
> > I'm not convinced (or well, even doubtful) this is something we want to
> > have at the expression evaluation level.
>
> Perhaps I'll discover the reason as I internalize the code, but could
> you expound a bit? Is that because you believe there's a better way to
> optimize subexpressions that don't change? Or that it's likely to add
> a lot of cost to non-optimized cases?

I think, if you're putting it into expression evaluation itself, the
likelihood of causing slowdowns outside of the cases you're trying to
optimize is much higher than likely the gain. Checks whether variables
haven't changed aren't free.

So, while I think it makes sense to optimize a constant array for a SAO
inside expression initialization (possibly with a different opcode), I
don't think runtime checking logic to see whether the array is still the
same in ExecEvalScalarArrayOp() or any related place is likely to be a
good idea.

If - I am not really convinced it's worth it - we really want to
optimize SAO arrays that can change at runtime, I suspect it'd be better
if we extended the param mechanism so there's a 'postprocessing' step
for params that changed.

Which then would have to apply the expression sub-tree that applies to
the Param (i.e. ScalarArrayOpExpr->args) into some place that is
accessible (or, even better, is directly accessed) by
ExecEvalScalarArrayOp().

I think you'll also have to be careful about whether using binary search
against the array will always come out top. I'd expect it to be worse
for the pretty common case of below 8 elements in the IN() or such.

Greetings,

Andres Freund