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

14 нояб. 2015 г., в 10:50, Amit Kapila <amit.kapila16@gmail.com> написал(а):

On Wed, Sep 16, 2015 at 11:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov
> <aekorotkov@gmail.com> wrote:
>
> >> I think it's reasonable to consider reporting this data in the PGPROC
> >> using a 4-byte integer rather than reporting it through a singe byte
> >> in the backend status structure.  I believe that addresses the
> >> concerns about reporting from auxiliary processes, and it also allows
> >> a little more data to be reported.  For anything in excess of that, I
> >> think we should think rather harder.  Most likely, such addition
> >> detail should be reported only for certain types of wait events, or on
> >> a delay, or something like that, so that the core mechanism remains
> >> really, really fast.
> >
> > That sounds reasonable. There are many pending questions, but it seems like
> > step forward to me.
>
> Great, let's do it.  I think we should probably do the work to
> separate the non-individual lwlocks into tranches first, though.
>

One thing that occurred to me in this context is that if we store the wait

event information in PGPROC, then can we think of providing the info

about wait events in a separate view pg_stat_waits (or pg_stat_wait_info or

any other better name) where we can display wait information about

all-processes rather than only backends?  This will avoid the confusion

about breaking the backward compatibility for the current 'waiting' column

in pg_stat_activity.

pg_stat_waits can have columns:

pid  - Process Id

wait_class_name - Name of the wait class

wait class_event  - name of the wait event

We can extend it later with the information about timing for wait event.

Also, if we follow this approach, I think we don't need to store this

information in PgBackendStatus.

  

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