On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote:
> On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, Aug 9, 2016 at 02:06:40AM +0000, Tsunakawa, Takayuki wrote:
> > I hope wait event monitoring will be on by default even if the overhead
> is not
> > almost zero, because the data needs to be readily available for faster
> > troubleshooting. IMO, the benefit would be worth even 10% overhead. If
> you
> > disable it by default because of overhead, how can we convince users to
> enable
> > it in production systems to solve some performance problem? I’m afraid
> severe
> > users would say “we can’t change any setting that might cause more
> trouble, so
> > investigate the cause with existing information.”
>
> If you want to know why people are against enabling this monitoring by
> default, above is the reason. What percentage of people do you think
> would be willing to take a 10% performance penalty for monitoring like
> this? I would bet very few, but the argument above doesn't seem to
> address the fact it is a small percentage.
>
>
> Just two notes from me:
>
> 1) 10% overhead from monitoring wait events is just an idea without any proof
> so soon.
> 2) We already have functionality which trades insight into database with way
> more huge overhead. auto_explain.log_analyze = true can slowdown queries *in
> times*. Do you think we should remove it?
The point is not removing it, the point is whether
auto_explain.log_analyze = true should be enabled by default, and I
think no one wants to do that.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
