Re: Tracking wait event for latches - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Tracking wait event for latches
Date
Msg-id CAA4eK1JXS+zO6dP1nShVAcf0dd8M+CCaHaMQWEk5mky+f9NC7A@mail.gmail.com
Whole thread Raw
In response to Re: Tracking wait event for latches  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Sep 23, 2016 at 7:02 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Sep 22, 2016 at 7:10 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>
>> I was thinking about suggesting a category "Replication" to cover the
>> waits for client IO relating to replication, as opposed to client IO
>> waits relating to regular user connections.  Then you could put sync
>> rep into that category instead of IPC, even though technically it is
>> waiting for IPC from walsender process(es), on the basis that it's
>> more newsworthy to a DBA that it's really waiting for a remote replica
>> to respond.  But it's probably pretty clear what's going on from the
>> the wait point names, so maybe it's not worth a category.  Thoughts?
>
> I thought about a replication category but either it will only have
> SyncRep in it, which is odd, or it will pull in other things that
> otherwise fit nicely into the Activity category, and then that
> boundaries of all the categories become mushy: is the subsystem that
> causes the wait that we are trying to document, or the kind of thing
> for which we are waiting?
>

I also think that it can add some confusion in defining boundaries and
also might not be consistent with current way we have defined the
waits, however there is some value in using subsystem which is that
user can identify the bottlenecks with ease.  I think this applies to
both Replication and Parallel Query.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Tracking wait event for latches
Next
From: Michael Paquier
Date:
Subject: Re: pg_ctl promote wait