Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
| От | David G. Johnston |
|---|---|
| Тема | Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) |
| Дата | |
| Msg-id | CAKFQuwanA21oTVct27LHC_RJBgxLFRbanyhH5fGug3+ti83uWQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
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 по дате отправления: