Re: stored procedure stats in collector - Mailing list pgsql-hackers

From Tom Lane
Subject Re: stored procedure stats in collector
Date
Msg-id 19469.1184550839@sss.pgh.pa.us
Whole thread Raw
In response to stored procedure stats in collector  (Martin Pihlak <martin.pihlak@gmail.com>)
Responses Re: stored procedure stats in collector  (Martin Pihlak <martin.pihlak@gmail.com>)
List pgsql-hackers
Martin Pihlak <martin.pihlak@gmail.com> writes:
> I'm working on a patch to extend the stats collector to handle stored procedure
> statistics (call counts, duration etc).
> ...
> Only functions with oid >= FirstNormalObjectId are accounted.

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.

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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: write_pipe_chunks patch messes up early error message output
Next
From: Tom Lane
Date:
Subject: Re: compiler warnings on the buildfarm