Re: RFC: replace pg_stat_activity.waiting with something more descriptive

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2016-03-18 17:54:59
Message-ID: 20160318175459.6g6mpzaszye4m6ia@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-03-18 11:01:04 -0400, Robert Haas wrote:
> On Thu, Mar 17, 2016 at 9:22 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > FWIW, my instinctive thought on the matter is to report the event
> > directly in WaitLatch() via a name of the event caller provided
> > directly in it. The category of the event is then defined
> > automatically as we would know its origin. The code path defining the
> > origin point from where a event type comes from is the critical thing
> > I think to define an event category. The LWLock events are doing that
> > in lwlock.c.
>
> I'm very skeptical of grouping everything that waits using latches as
> a latch wait, but maybe it's OK to do it that way. I was thinking
> more of adding categories like "client wait" with events like "client
> read" and "client write".

+1. I think categorizing latch waits together will be pretty much
meaningless. We use the same latch for a lot of different things, and
the context in which we're waiting is the important bit.

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-18 18:00:58 Re: Performance degradation in commit ac1d794
Previous Message Andres Freund 2016-03-18 17:53:36 Re: Performance degradation in commit ac1d794