Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Amit Kapila |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CAA4eK1JHranT6uyS29EjmozMHxJrY699CMGKL89sYBcxf12f1A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
|
Список | pgsql-hackers |
On Wed, Jan 20, 2016 at 6:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jan 19, 2016 at 11:49 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> On the topic of the UI, I understand that redefining
> >> pg_stat_activity.waiting might cause some short-term annoyance. But I
> >> think in the long term what we are proposing here is going to be a
> >> huge improvement, so I think it's worth the compatibility break. If
> >> we say that pg_stat_activity.waiting has to continue meaning "waiting
> >> for a heavyweight lock" even though we now also expose (in some other
> >> location) information on other kinds of waits, that's going to be
> >> confusing to users.
> >
> > If we want to go via this route, then the first thing which we need to
> > decide is whether we want to start displaying the information of
> > background processes like WALWriter and others in pg_stat_activity?
>
> That doesn't seem like a particularly good fit - few of the fields are
> relevant to that case. We could provide some other way of getting at
> the information for background processes if people want, but
> personally I'd probably be inclined not to bother with it for right
> now.
>
>
> On Tue, Jan 19, 2016 at 11:49 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> On the topic of the UI, I understand that redefining
> >> pg_stat_activity.waiting might cause some short-term annoyance. But I
> >> think in the long term what we are proposing here is going to be a
> >> huge improvement, so I think it's worth the compatibility break. If
> >> we say that pg_stat_activity.waiting has to continue meaning "waiting
> >> for a heavyweight lock" even though we now also expose (in some other
> >> location) information on other kinds of waits, that's going to be
> >> confusing to users.
> >
> > If we want to go via this route, then the first thing which we need to
> > decide is whether we want to start displaying the information of
> > background processes like WALWriter and others in pg_stat_activity?
>
> That doesn't seem like a particularly good fit - few of the fields are
> relevant to that case. We could provide some other way of getting at
> the information for background processes if people want, but
> personally I'd probably be inclined not to bother with it for right
> now.
>
I have updated the patch accordingly. pg_stat_get_activity.waiting is
changed to a text column wait_event and currently it will display the
heavy-weight and light-weight lock information for backends, certainly
it can be extended to report network wait or disk wait events, but I feel
that can be done as an add-on patch. For LWLocks, it returns LWLock
name for individual locks and tranche name for others.
Вложения
В списке pgsql-hackers по дате отправления: