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.
In fact, the argument above goes even farther, saying that we should
enable it all the time because people will be unwilling to enable it on
their own. I have to question the value of the information if users are
not willing to enable it. And the solution proposed is to force the 10%
default overhead on everyone, whether they are currently doing
debugging, whether they will ever do this level of debugging, because
people will be too scared to enable it. (Yes, I think Oracle took this
approach.)
We can talk about this feature all we want, but if we are not willing to
be realistic in how much performance penalty the _average_ user is
willing to lose to have this monitoring, I fear we will make little
progress on this feature.
-- 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 +
