On 2016-11-26 08:41:28 -0800, Andres Freund wrote:
> On November 26, 2016 8:06:26 AM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >Robert Haas <robertmhaas@gmail.com> writes:
> >> On Fri, Nov 25, 2016 at 11:12 PM, Andres Freund <andres@anarazel.de>
> >wrote:
> >>> while working on my faster expression evaluation stuff I noticed
> >that a
> >>> lot of expression types that call functions don't call the necessary
> >>> functions to make track_functions work.
> >>>
> >>> ExecEvalFunc/ExecEvalOper (via ExecMakeFunctionResultNoSets) call
> >>> pgstat_init_function_usage/pgstat_end_function_usage, but others
> >like
> >>> ExecEvalRowCompare, ExecEvalMinMax, ExecEvalNullIf,
> >ExecEvalDistinct,
> >>> ExecEvalScalarArrayOp (and indirectly ExecEvalArrayCoerceExpr)
> >don't.
> >>>
> >>> Similarly InvokeFunctionExecuteHook isn't used very thoroughly.
> >>>
> >>> Are these worth fixing? I suspect yes. If so, do we want to
> >backpatch?
> >
> >Those don't call functions, they call operators. Yes, I know that an
> >operator has a function underlying it, but the user-level expectation
> >for
> >track_functions is that what it counts are things that look
> >syntactically
> >like function calls. I'm not eager to add tracking overhead for cases
> >that there's been exactly zero field demand for.
>
> But we do track for OpExprs? Otherwise I'd agree.
Bump?
- Andres