2016-08-09 11:49 GMT+09:00 Joshua D. Drake <j...@commandprompt.com>: > On 08/08/2016 07:37 PM, Bruce Momjian 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. > > > I would argue it is zero. There are definitely users for this feature but to > enable it by default is looking for trouble. *MOST* users do not need this.
I used to think of that this kind of features should be enabled by default, because when I was working at the previous company, I had only few features to understand what is happening inside PostgreSQL by observing production databases. I needed those features enabled in the production databases when I was called. However, now I have another opinion. When we release the next major release saying 10.0 with the wait monitoring, many people will start their benchmark test with a configuration with *the default values*, and if they see some performance decrease, for example around 10%, they will be talking about it as the performance decrease in PostgreSQL 10.0. It means PostgreSQL will be facing difficult reputation. So, I agree with the features should be disabled by default for a while. Regards, -- Satoshi Nagayasu <sn...@uptime.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers