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:
http://www.postgresql.org/mailpre
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 m
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 "
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 a
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
> tha
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). Re
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"
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 na
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
func
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 co
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 f
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
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
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
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 overhe
16 matches
Mail list logo
