<p dir="ltr">2016/08/10 23:22 "Bruce Momjian" <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>>:<br />
><br/> > On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote:<br /> > > On Tue, Aug 9, 2016
at5:37 AM, Bruce Momjian <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>> wrote:<br /> > ><br />
>> On Tue, Aug 9, 2016 at 02:06:40AM +0000, Tsunakawa, Takayuki wrote:<br /> > > > I hope wait
eventmonitoring will be on by default even if the overhead<br /> > > is not<br /> > > > almost
zero,because the data needs to be readily available for faster<br /> > > > troubleshooting. IMO, the
benefitwould be worth even 10% overhead. If<br /> > > you<br /> > > > disable it by default
becauseof overhead, how can we convince users to<br /> > > enable<br /> > > > it in production
systemsto solve some performance problem? I’m afraid<br /> > > severe<br /> > > > users would
say“we can’t change any setting that might cause more<br /> > > trouble, so<br /> > > >
investigatethe cause with existing information.”<br /> > ><br /> > > If you want to know why people are
againstenabling this monitoring by<br /> > > default, above is the reason. What percentage of people do you
think<br/> > > would be willing to take a 10% performance penalty for monitoring like<br /> > >
this? I would bet very few, but the argument above doesn't seem to<br /> > > address the fact it is a small
percentage.<br/> > ><br /> > ><br /> > > Just two notes from me:<br /> > ><br /> > > 1)
10%overhead from monitoring wait events is just an idea without any proof<br /> > > so soon.<br /> > > 2)
Wealready have functionality which trades insight into database with way<br /> > > more huge
overhead. auto_explain.log_analyze= true can slowdown queries *in<br /> > > times*. Do you think we should
removeit?<br /> ><br /> > The point is not removing it, the point is whether<br /> > auto_explain.log_analyze
=true should be enabled by default, and I<br /> > think no one wants to do that.<p dir="ltr">Agreed.<p dir="ltr">If
peopleare facing with some difficult situation in terms of performance, they may accept some (one-time) overhead to
resolvethe issue.<br /> But if they don't have (recognize) any issue, they may not.<p dir="ltr">That's one of the
realitiesaccording to my experiences.<p dir="ltr">Regards,
