>>>>> "Daniel" == Daniel Migowski <dmigowski@ikoffice.de> writes:
Daniel> Ok, then no statistics for me :). If this is intentional, a
Daniel> small line or warning in the docs would be helpful.
There's a workaround, though it's a somewhat bizarre one:
If you apply any SET clause to the definition of a function, then calls
to it will be tracked (if either track_functions is globally enabled or
if the SET clause enables it) regardless of the context the function is
called in. This is also true for security definer functions.
This doesn't seem to be entirely intentional, it is fallout from the
ability to do SET track_functions = ... in the definition of a specific
function and have it take effect for that specific call.
(There is some overhead with this, since SET clauses or secdef are
implemented using a shim between the function and its caller, but the
overhead should be much less than a plpgsql wrapper. Also, this will
disable inlining of the function if it is LANGUAGE SQL.)
Daniel> I also wonder if in and out functions of datatypes are tracked
Daniel> (As they a C functions) or if there are other places where
Daniel> function tracking isn't implemented although the functions get
Daniel> called (maybe on index creation, etc.). I need this information
Daniel> because I currently try to decide if I have to convert some of
Daniel> these functions to native c functions.
As far as I can tell, only the following cases are tracked:
- functions called as triggers or event triggers
- functions called from the expression evaluator
- functions called as FROM-clause entries in queries
- any function which has a SET clause or is SECURITY DEFINER
Not tracked are any other cases, which include:
- the function-call fastpath from clients
- window functions and aggregate functions
- functions used for sort/group/distinct/hash comparisons
- index support functions
- input and output functions
- estimation functions
- any case where a function calls another function without going
via SQL
--
Andrew (irc:RhodiumToad)