Re: stored procedure stats in collector
От | Hans-Juergen Schoenig |
---|---|
Тема | Re: stored procedure stats in collector |
Дата | |
Msg-id | 84E2E70E-4B94-4FB3-ABCA-C177BE993451@cybertec.at обсуждение исходный текст |
Ответ на | Re: stored procedure stats in collector (Volkan YAZICI <yazicivo@ttmail.com>) |
Список | pgsql-patches |
On Mar 23, 2008, at 9:25 PM, Volkan YAZICI wrote:
Hi,On Sun, 23 Mar 2008, Martin Pihlak <martin.pihlak@gmail.com> writes:Attached is a patch that enables tracking function calls throughthe stats subsystem. Original discussion:Introduces new guc variable - track_functions. Possible values are:none - no collection, defaultpl - tracks procedural language functionsall - tracks procedural, SQL and C (not internal) functionsI might have missed the discussion, but I'd love to see a more flexibleinterface for configuration parameters. For instance, it'd be great ifwe can specify which procedural languages to track in the `pl' GUC.Moreover, if it'd be possible to specify which specific functions wewant to try, then that would be awesome as well.For instance, possible configuration combinations for track_functionscan 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 publicschema.`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 Icome up with for the very moment.) And I'm aware of the overhead andcomplexity(?) this sort of scheme will bring, but I really want to usesuch 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
В списке pgsql-patches по дате отправления: