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