On Mar 23, 2008, at 9:25 PM, Volkan YAZICI wrote:
Hi,
Attached is a patch that enables tracking function calls through
the stats subsystem. Original discussion:
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
