Re: Waits monitoring

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Waits monitoring
Date: 2015-09-07 10:58:24
Message-ID: CAPpHfdv9zqMoXdxfJJRB-QCTLdUW1O=-Knd496GdGE8HiH8OFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 7, 2015 at 6:28 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Sun, Sep 6, 2015 at 5:58 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > On 2015-09-04 23:44:21 +0100, Simon Riggs wrote:
> > > I see the need for both current wait information and for cumulative
> > > historical detail.
> > >
> > > I'm willing to wait before reviewing this, but not for more than 1
> more CF.
> > >
> > > Andres, please decide whether we should punt to next CF now, based upon
> > > other developments. Thanks
> >
> > I think we can do some of the work concurrently - the whole lwlock
> > infrastructure piece is rather independent and what currently most of
> > the arguments are about. I agree that the actual interface will need to
> > be coordinated.
> >
> > Ildus, could you please review Amit & Robert's patch?
> >
>
> Are you talking about patch where I have fixed few issues in Robert's
> patch [1] or the original patch [3] written by me.
>

AFAICS, Andres meant [3].

[1] -
> http://www.postgresql.org/message-id/CAA4eK1KdeC1Tm5ya9gkV85Vtn4qqsRxzKJrU-tu70G_tL1xkFA@mail.gmail.com
> [2] -
> http://www.postgresql.org/message-id/3F71DA37-A17B-4961-9908-016E6323E612@postgrespro.ru
> [3] -
> http://www.postgresql.org/message-id/CAA4eK1Kt2e6XhViGisR5o1aC9NfO0j2wTb8N0ggD1_JkLdeKdQ@mail.gmail.com
>

For me, major issues of [3] are:
1) We fit all information about current wait event into single byte.
2) We put this byte into PgBackendStatus.
Both of these issues are essential for design of [3].

Issue #1 means that we actually can expose to user only event type (until
there are less then 256 types) with no parameters [4].
Issue #2 means that we have to monitor only backend not auxiliary processes
[5].

Both of these issues seems to be serious limitations for me. It makes me
think we either need a different design or need to expose current wait
event in some other way additionally. Anyway, I think attracting more
attention to this problem is good. It would be very nice if Simon or Andres
give review of this.

[4] -
http://www.postgresql.org/message-id/CAPpHfdtdF8LyR0zBA_tzAwYq00GFZyVbh_XfFAABRQQ=MBnxAA@mail.gmail.com
[5] - http://www.postgresql.org/message-id/55C3306B.5010401@postgrespro.ru

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2015-09-07 11:30:06 Fwd: [Snowball-discuss] New website
Previous Message Shulgin, Oleksandr 2015-09-07 09:55:23 Re: On-demand running query plans using auto_explain and signals