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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings