From: | Satoshi Nagayasu <snaga(at)uptime(dot)jp> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, ik(at)postgresql-consulting(dot)com, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Wait events monitoring future development |
Date: | 2016-08-10 14:37:36 |
Message-ID: | CAA8sozcNex6tu9g9EtsrWQsu8-=CTSNg6EB+WKMg7z0eHht-2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016/08/10 23:22 "Bruce Momjian" <bruce(at)momjian(dot)us>:
>
> On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote:
> > On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian <bruce(at)momjian(dot)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?
>
> The point is not removing it, the point is whether
> auto_explain.log_analyze = true should be enabled by default, and I
> think no one wants to do that.
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 of the realities according to my experiences.
Regards,
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-08-10 14:43:47 | Re: Wait events monitoring future development |
Previous Message | Heikki Linnakangas | 2016-08-10 14:30:57 | Re: Proposal for CSN based snapshots |