Skip site navigation (1) Skip section navigation (2)

Re: stored procedure stats in collector

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: Volkan YAZICI <yazicivo(at)ttmail(dot)com>
Cc: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>, pgsql-patches(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: stored procedure stats in collector
Date: 2008-03-24 08:35:33
Message-ID: 84E2E70E-4B94-4FB3-ABCA-C177BE993451@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Mar 23, 2008, at 9:25 PM, Volkan YAZICI wrote:

> Hi,
>
> On Sun, 23 Mar 2008, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:
>> Attached is a patch that enables tracking function calls through
>> the stats subsystem. Original discussion:
>> http://archives.postgresql.org/pgsql-hackers/2007-07/msg00377.php
>>
>> Introduces new guc variable - track_functions. Possible values are:
>> none - no collection, default
>> pl - tracks procedural language functions
>> all - tracks procedural, SQL and C (not internal) functions
>
> I might have missed the discussion, but I'd love to see a more  
> flexible
> interface for configuration parameters. For instance, it'd be great if
> we can specify which procedural languages to track in the `pl' GUC.
> Moreover, if it'd be possible to specify which specific functions we
> want to try, then that would be awesome as well.
>
> For instance, possible configuration combinations for track_functions
> can be:
>
>   `pl:*'                - Tracks procedural, SQL and C (not internal)
>                           functions in the `public' schema.
>   `pl:pgsql'            - Tracks only PL/pgSQL functions.
>   `pl:scheme'           - Tracks only PL/scheme functions.
>   `foo(int, int)'       - Tracks related `foo' function in the public
>                           schema.
>   `stock.foo(int, int)' - Tracks related `foo' function in the `stock'
>                           schema.
>   `pl:stock.*'          - Tracks procedural, SQL and C (not internal)
>                           functions in the `stock' schema.
>
> Syntax can obviously be much more consistent. (These are just what I
> come up with for the very moment.) And I'm aware of the overhead and
> complexity(?) this sort of scheme will bring, but I really want to use
> such a useful feature with mentioned flexibilities.
>
>


this patch is quite cool already.
it would be even cooler if we could define on a per-function basis.
eg. CREATE FUNCTION ... TRACK | NOTRACK
in addition to that we could define a GUC defining whether TRACK or  
NOTRACK is used as default.
in many cases you are only interested in a special set of functions  
anyway.
as every operator is basically a procedure in postgres, i am not  
quite happy about the per-language  approach.

	best regards,

		hans


--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com

In response to

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2008-03-24 09:21:54
Subject: Re: Project idea for Google Summer of Code
Previous:From: Дмитрий КирилловDate: 2008-03-24 06:42:58
Subject: Project idea for Google Summer of Code

pgsql-patches by date

Next:From: Brendan JurdDate: 2008-03-24 10:37:36
Subject: Re: [HACKERS] quote_literal with NULL
Previous:From: Volkan YAZICIDate: 2008-03-23 20:25:45
Subject: Re: stored procedure stats in collector

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group