Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Date
Msg-id CAKFQuwanA21oTVct27LHC_RJBgxLFRbanyhH5fGug3+ti83uWQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Dec 12, 2016 at 9:19 AM, Robert Haas <robertmhaas@gmail.com> wrote:
So, one of the problems in this patch as committed is that for any
process that doesn't show up in pg_stat_activity, there's no way to
see the wait event information.  That sucks.  I think there are
basically two ways to fix this:

1. Show all processes that have a PGPROC in pg_stat_activity,
including auxiliary processes and whatnot, and use some new field in
pg_stat_activity to indicate the process type.

2. Add a second view, say pg_stat_system_activity, to show the
processes that don't appear in pg_stat_activity.  A bunch of columns
could likely be omitted, but there would be some duplication, too.

Preferences?


​I'm inclined toward option 2.

A view over both that involves just the shared columns would give you the benefits from option 1.

Question: is there a parent-child relationship involved here?  Given a record in today's pg_stat_activity is it useful/possible to link in all of the pg_stat_system_activity​ process that are working to fulfill the client-initiated task?

Even with "system" we'd probably want to distinguish between background workers and true system maintenance processes.  Or am I mis-interpreting the scope of this feature?

David J.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)