Re: [HACKERS] Wait events monitoring future development

2016-08-16 Thread Andres Freund
Hi, On 2016-08-07 14:03:17 +0200, Ilya Kosmodemiansky wrote: > Wait event monitoring looks ones again stuck on the way through community > approval in spite of huge progress done last year in that direction. I see little evidence of that. If you consider "please do some reasonable benchmarks" as

Re: [HACKERS] Wait events monitoring future development

2016-08-10 Thread Robert Haas
On Tue, Aug 9, 2016 at 12:07 AM, Tsunakawa, Takayuki wrote: > As another idea, we can stand on the middle ground. Interestingly, MySQL > also enables their event monitoring (Performance Schema) by default, but not > all events are collected. I guess highly

Re: [HACKERS] Wait events monitoring future development

2016-08-10 Thread Bruce Momjian
On Wed, Aug 10, 2016 at 11:37:36PM +0900, Satoshi Nagayasu wrote: > Agreed. > > If people are facing with some difficult situation in terms of performance, > they may accept some (one-time) overhead to resolve the issue. > But if they don't have (recognize) any issue, they may not. > > That's

Re: [HACKERS] Wait events monitoring future development

2016-08-10 Thread Satoshi Nagayasu
2016/08/10 23:22 "Bruce Momjian" : > > On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote: > > On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian wrote: > > > > On Tue, Aug 9, 2016 at 02:06:40AM +, Tsunakawa, Takayuki wrote: > > > I hope

Re: [HACKERS] Wait events monitoring future development

2016-08-10 Thread Bruce Momjian
On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote: > On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian wrote: > > On Tue, AugĀ  9, 2016 at 02:06:40AM +, Tsunakawa, Takayuki wrote: > > I hope wait event monitoring will be on by default even if the

Re: [HACKERS] Wait events monitoring future development

2016-08-10 Thread Alexander Korotkov
On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian wrote: > On Tue, Aug 9, 2016 at 02:06:40AM +, 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

Re: [HACKERS] Wait events monitoring future development

2016-08-10 Thread Alexander Korotkov
On Tue, Aug 9, 2016 at 12:47 AM, Ilya Kosmodemiansky < ilya.kosmodemian...@postgresql-consulting.com> wrote: > On Mon, Aug 8, 2016 at 7:03 PM, Bruce Momjian wrote: > > It seems asking users to run pg_test_timing before deploying to check > > the overhead would be sufficient. >

Re: [HACKERS] Wait events monitoring future development

2016-08-10 Thread Craig Ringer
On 10 August 2016 at 07:09, Jim Nasby wrote: > > The downside to leaving stuff like this off by default is users won't > remember it's there when they need it. At best, that means they spend more > time debugging something than they need to. At worse, it means they

Re: [HACKERS] Wait events monitoring future development

2016-08-09 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > Lets put this in perspective: there's tons of companies that spend thousands > of dollars per month extra by running un-tuned systems in cloud environments. > I almost called that "waste" but in reality it should be a simple business > question: is it

Re: [HACKERS] Wait events monitoring future development

2016-08-09 Thread Jim Nasby
On 8/8/16 11:07 PM, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org > 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

Re: [HACKERS] Wait events monitoring future development

2016-08-09 Thread Bruce Momjian
On Tue, Aug 9, 2016 at 04:17:28AM +, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org > > 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

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > 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

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > 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

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Satoshi Nagayasu
2016-08-07 21:03 GMT+09:00 Ilya Kosmodemiansky : > I've summarized Wait events monitoring discussion at Developer unconference > in Ottawa this year on wiki: > > https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference/Wait_events_monitoring

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Satoshi Nagayasu
2016-08-09 11:49 GMT+09:00 Joshua D. Drake : > On 08/08/2016 07:37 PM, Bruce Momjian wrote: >> >> On Tue, Aug 9, 2016 at 02:06:40AM +, Tsunakawa, Takayuki wrote: >>> >>> I hope wait event monitoring will be on by default even if the overhead >>> is not >>> almost zero,

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Joshua D. Drake
On 08/08/2016 07:37 PM, Bruce Momjian wrote: On Tue, Aug 9, 2016 at 02:06:40AM +, 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

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Bruce Momjian
On Tue, Aug 9, 2016 at 02:06:40AM +, 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

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ilya Kosmodemiansky I've summarized Wait events monitoring discussion at Developer unconference in Ottawa this year on wiki:

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Bruce Momjian
On Mon, Aug 8, 2016 at 11:47:11PM +0200, Ilya Kosmodemiansky wrote: > On Mon, Aug 8, 2016 at 7:03 PM, Bruce Momjian wrote: > > It seems asking users to run pg_test_timing before deploying to check > > the overhead would be sufficient. > > I'am not sure. Time measurement for

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Ilya Kosmodemiansky
On Mon, Aug 8, 2016 at 7:03 PM, Bruce Momjian wrote: > It seems asking users to run pg_test_timing before deploying to check > the overhead would be sufficient. I'am not sure. Time measurement for waits is slightly more complicated than a time measurement for explain analyze: a

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Jeff Janes
On Mon, Aug 8, 2016 at 10:03 AM, Bruce Momjian wrote: > On Mon, Aug 8, 2016 at 04:43:40PM +0530, Amit Kapila wrote: >> >According to developers, overhead is small, but many people have doubts >> > that it can be much more significant for intensive workloads. Obviously, it

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Bruce Momjian
On Mon, Aug 8, 2016 at 04:43:40PM +0530, Amit Kapila wrote: > >According to developers, overhead is small, but many people have doubts > > that it can be much more significant for intensive workloads. Obviously, it > > is not an easy task to test, because you need to put doubtfully > >

Re: [HACKERS] Wait events monitoring future development

2016-08-08 Thread Amit Kapila
On Sun, Aug 7, 2016 at 5:33 PM, Ilya Kosmodemiansky wrote: > Hi, > > I've summarized Wait events monitoring discussion at Developer unconference > in Ottawa this year on wiki: > >

[HACKERS] Wait events monitoring future development

2016-08-07 Thread Ilya Kosmodemiansky
Hi, I've summarized Wait events monitoring discussion at Developer unconference in Ottawa this year on wiki: https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference/Wait_events_monitoring (Thanks to Alexander Korotkov for patiently pushing me to make this thing finally done) If you