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?
------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
