Tom Lane wrote:
> I really dislike that approach to deciding which functions to count.
> The main problem with it is that it will try to count C-language
> functions that are added after initdb, such as contrib stuff and
> third-party add-ons like postgis. The percentage overhead for a
> typical short C function will be large, and I'm not sure anything
> much is to be gained by counting these.
>
Agreed, it is a bit ugly. In the initial version there was no such
exclusion. This came only after I "accidentally" activated the
collection on a busy server. Checked cpu usage some half an hour later
and immediately disabled it. System mode consumption was unacceptably
high, but the results indicated that something funny was going
on inside application as well - some internal functions such as texteq()
and now() had unreasonably high call counts. I'm still investigating
those issues, but maybe it might be useful to have stats for internal
and C language functions as well?
Perhaps it is possible to make the collection configurable per language.
So that for instance, default is to only collect pl languages, with the
option to add C or internal. Not sure how to approach this though.
> I think a more reasonable approach would be to count PL-language
> functions; which in turn suggests that the instrumentation hooks
> should be in the PL call handlers, not in ExecMakeFunctionResult
> and friends where they will drag down performance of all functions.
>
It would be great if all the procedural languages would go through a
single entry point. Right now the more exotic PL-s would need separate
patching. But indeed, this approach would be less intrusive.
> BTW, I dunno if you've thought about the implications of inlining
> of SQL functions ... it's hard to see how to count those reasonably.
>
Yes, this creates some inconsistencies in what is collected and what not.
Unless, of course, only PL functions are counted :)
Regards,
Martin
