2016/08/10 23:22 "Bruce Momjian" <br...@momjian.us>: > > On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote: > > On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian <br...@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.
Agreed. If people are facing with some difficult situation in terms of performance, they may accept some (one-time) overhead to resolve the issue. But if they don't have (recognize) any issue, they may not. That's one of the realities according to my experiences. Regards,
