On 2016-11-26 08:41:28 -0800, Andres Freund wrote: > On November 26, 2016 8:06:26 AM PST, Tom Lane <t...@sss.pgh.pa.us> wrote: > >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. > > But we do track for OpExprs? Otherwise I'd agree.
Bump? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
