Hi, On 2020-04-12 08:55:44 -0400, James Coleman wrote: > On Sat, Apr 11, 2020 at 5:32 PM Andres Freund <and...@anarazel.de> wrote: > > On 2020-04-11 15:53:11 -0400, James Coleman wrote: > > > On Sat, Apr 11, 2020 at 2:01 PM Andres Freund <and...@anarazel.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
