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
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 encountered events are not
> collect
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 one
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 wait event monitoring will be on by
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 overhead
> is not
>
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 faster
> > troublesh
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.
>
> I'am not sure. Ti
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 suffer
> a production outage f
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 wort
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 monito
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 h
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 thos
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 a
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
>
> (Thanks to Alexander Korotkov for patiently
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, because the data needs t
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 benef
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 y
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:
https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference/Wait_e
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 waits is slightly mor
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 good workload plus
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
>> > is not an easy
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
> > non-pro
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:
>
> https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference/Wait_events_monitoring
>
>
> (Thanks to Alexander K
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
24 matches
Mail list logo
