Re: Skipping PgStat_FunctionCallUsage for many expressions

On November 26, 2016 8:06:26 AM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Nov 25, 2016 at 11:12 PM, Andres Freund <andres(at)anarazel(dot)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.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.