Re: stored procedure stats in collector
От | Martin Pihlak |
---|---|
Тема | Re: stored procedure stats in collector |
Дата | |
Msg-id | 46F7B748.7040105@gmail.com обсуждение исходный текст |
Ответ на | Re: stored procedure stats in collector (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: stored procedure stats in collector
|
Список | pgsql-hackers |
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 are deprecated now. Will rename to "track_functions" and change values to "off", "pl" and "all". Or should I use "none" instead of "off"? > I'm curious if you've measured the performance overhead of enabling this > functionality. > Just finished a simple benchmark comparing unpatched, "off" and "all": unpatched usr sys total dummy 21.36 0.68 22.04 rfact 51.52 0.07 51.59 ifact 20.40 0.06 20.45 "off" usr sys total diff x dummy 21.59 0.39 21.97 1.00 rfact 52.40 0.06 52.46 1.02 ifact 20.78 0.02 20.8 1.02 "all" usr sys total diff x dummy 21.69 35.18 56.87 2.58 rfact 47.83 38.99 86.83 1.68 ifact 20.65 0.36 21.01 1.03 dummy is blank pl/pgsql function (ran 10000000 times). rfact is recursive factorial, ifact is iterative (both ran 1000000 times). Comparing median of 3 runs. The usr and sys values are from log_executor_stats. It seems that the overhead is unnoticeable if disabled, very visible for lightweight functions and heavy callers. Almost unnoticeable for more compute intensive functions. >> PS. Would something like this be a canditate for 8.4 inclusion (if polished up)? > > It sounds like a useful feature to me. > Good. I'll bring the patch up to date with HEAD. Regards, Martin
В списке pgsql-hackers по дате отправления: