track_functions default

Started by Magnus Haganderabout 15 years ago4 messages
#1Magnus Hagander
magnus@hagander.net

Is there a particular reason why track_functions is disabled by default?

Does having it at 'pl' by default create a noticable overhead for
people who aren't using pl functions? Or for that matter, even a
noticable overhead for those that *are*?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#1)
Re: track_functions default

Magnus Hagander <magnus@hagander.net> writes:

Is there a particular reason why track_functions is disabled by default?

Performance worries, plus the thought that not everyone cares to
have these stats.

Does having it at 'pl' by default create a noticable overhead for
people who aren't using pl functions? Or for that matter, even a
noticable overhead for those that *are*?

I think we determined it did; and as for those who aren't using pl
functions, there'd be no benefit to such a change anyway.

regards, tom lane

#3Magnus Hagander
magnus@hagander.net
In reply to: Tom Lane (#2)
Re: track_functions default

On Tue, Nov 16, 2010 at 16:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Is there a particular reason why track_functions is disabled by default?

Performance worries, plus the thought that not everyone cares to
have these stats.

Most people who are actively using stored procedures probably do. And
most don't know about it, so they don't turn it on. Which means that
in order to do anything, you have to first turn it on and then wait
for a long time (whatever a reasonable cycle is) before you can start
using it. Having it on by default would help in a lot of those cases.

Does having it at 'pl' by default create a noticable overhead for
people who aren't using pl functions? Or for that matter, even a
noticable overhead for those that *are*?

I think we determined it did; and as for those who aren't using pl
functions, there'd be no benefit to such a change anyway.

Ok, if it does have a noticable performance impact, I can see why it's
off by default. If it's only a tiny one, I would suggest it be on by
default - simply so people have it there by default. If you're tuning
your server for that last little bit of performance, you're touching a
whole bunch of other settings anyway, so turning it off isn't a big
deal....

I guess I should've done some actual measurements before posting :D

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

#4Cédric Villemain
cedric.villemain.debian@gmail.com
In reply to: Magnus Hagander (#3)
Re: track_functions default

2010/11/16 Magnus Hagander <magnus@hagander.net>:

On Tue, Nov 16, 2010 at 16:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Is there a particular reason why track_functions is disabled by default?

Performance worries, plus the thought that not everyone cares to
have these stats.

Most people who are actively using stored procedures probably do. And
most don't know about it, so they don't turn it on. Which means that
in order to do anything, you have to first turn it on and then wait
for a long time (whatever a reasonable cycle is) before you can start
using it. Having it on by default would help in a lot of those cases.

Does having it at 'pl' by default create a noticable overhead for
people who aren't using pl functions? Or for that matter, even a
noticable overhead for those that *are*?

I think we determined it did; and as for those who aren't using pl
functions, there'd be no benefit to such a change anyway.

Ok, if it does have a noticable performance impact, I can see why it's
off by default. If it's only a tiny one, I would suggest it be on by
default - simply so people have it there by default. If you're tuning
your server for that last little bit of performance, you're touching a
whole bunch of other settings anyway, so turning it off isn't a big
deal....

I agree, this parameter is not used a lot, but is very usefull.

I guess I should've done some actual measurements before posting :D

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support