Andres Freund <and...@anarazel.de> writes: > On 2020-04-11 08:58:46 -0400, James Coleman wrote: >> - Does the execExpr/execExprInterp framework allow a scalar array op >> to get an already expanded array (unless I'm missing something we >> can't easily lookup a given index in a flattened array)?
> Well, I'm not quite sure what you're thinking of. If the input is > constant, then expression initialization can do just about everything it > wants. Including preprocessing the array into whatever form it wants. > But there's no logic for doing preprocessing whenever values change. For the most part it seems like this is asking the question at the wrong level. It's not execExpr's job to determine the form of either values coming in from "outside" (Vars from table rows, or Params from elsewhere) or the results of intermediate functions/operators. In the specific case of an array-valued (or record-valued) Const node, you could imagine having a provision to convert the array/record to an expanded datum at execution start, or maybe better on first use. I'm not sure how to tell whether that's actually a win though. It could easily be a net loss if the immediate consumer of the value wants a flat datum. It seems like this might be somewhat related to the currently-moribund patch to allow caching of the values of stable subexpressions from one execution to the next. If we had that infrastructure you could imagine extending it to allow caching the expanded not flat form of some datums. Again I'm not entirely sure what would drive the choice. > I wonder if it would be a good idea to change ExecEvalParamExec and > ExecEvalParamExtern to detoast the to-be-returned value. If we change > the value that's stored in econtext->ecxt_param_exec_vals / > econtext->ecxt_param_list_info, we'd avoid repeated detaosting. I'd think about attaching that to the nestloop param mechanism not ExecEvalParam in general. regards, tom lane