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 <br...@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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers