Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Nov 25, 2016 at 11:12 PM, Andres Freund <and...@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.
> If it doesn't torpedo performance, I assume we should fix and back-patch.
It's certainly not going to help.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
