On 2017-02-14 17:58:23 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > 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: > >>> 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? > > If you're going to insist on foolish consistency, I'd rather take out > tracking in OpExpr than add it in dozens of other places.
I'm ok with being inconsistent, but I'd like to make that a conscious choice rather it being the consequence of an oversight - and that's what it looks like to me. We're doing it for OpExpr, but not for a bunch of other function / operator invocations within execQual.c (namely ExecEvalDistinct, ExecEvalScalarArrayOp, ExecEvalRowCompare, ExecEvalMinMax, ExecEvalNullIf), neither do we do it for *function* invocations directly in the executor (prominently node[Window]Agg.c), but we do it for trigger invocations. That's, uh, a bit weird and hard to explain. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers