This has been saved for the next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martin Pihlak wrote:
Howdy,
Here's an updated version of the function stats patch. The biggest change is
Howdy,
Did you post an updated patch to HEAD?
No, but I guess its just about time. Hopefully I'll have
something to show next week.
regards,
Martin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi,
Good. I'll bring the patch up to date with HEAD.
Did you post an updated patch to HEAD?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martin Pihlak wrote:
Howdy,
Here's an updated version of the function stats patch. The biggest change is
that
On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote:
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
functionality.
i'm quite worried about all setting.
all operators are
hubert depesz lubaczewski wrote:
On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote:
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
functionality.
i'm quite worried about all
Neil Conway wrote:
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
Makes sense. It appears that the stats_ prefixed GUC names
Martin Pihlak [EMAIL PROTECTED] writes:
Neil Conway wrote:
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
Makes sense. It appears that the stats_ prefixed GUC names are deprecated now.
Will rename to track_functions and change values to off, pl and
all. Or
It seems that the overhead is unnoticeable if disabled, very visible
for lightweight functions and heavy callers. Almost unnoticeable for
more compute intensive functions.
The very high system times seem odd. Maybe you have a machine with
slow gettimeofday()?
So it seems (on Ubuntu 7.04).
Howdy,
Here's an updated version of the function stats patch. The biggest change is
that by default only procedural language functions are counted. The GUC variable
stats_function_level now takes 3 values: on, off and all. The latter also
counts SQL and C language functions, on means only to
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
Neil Conway wrote:
(schemaname, procname, nargs) is still ambiguous in the face of function
overloading. Although the presence of procid uniquely identifies each
function anyway, if you're going to include the name and argument
information, it might be worth including the argument types as well
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
Martin Pihlak [EMAIL PROTECTED] 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
Howdy,
I'm working on a patch to extend the stats collector to handle stored procedure
statistics (call counts, duration etc). The goal is to make this information
visible via pg_stat functions/views. The collection would be controllable via
stats_function_level GUC and will have minimal
On Fri, 2007-07-13 at 14:11 +0300, Martin Pihlak wrote:
I'm working on a patch to extend the stats collector to handle stored
procedure
statistics (call counts, duration etc). The goal is to make this information
visible via pg_stat functions/views. The collection would be controllable via
16 matches
Mail list logo
