On Fri, Jun 26, 2015 at 9:01 AM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> On Thu, Jun 25, 2015 at 6:46 AM, Andres Freund <
andres@anarazel.de> wrote:
> >> 1. Remove/Change 'waiting' in pg_stat_activity and break the backward
> >> compatibility. I think we should try to avoid going via this route.
> >>
> >> 2. Add 2 new columns to pg_stat_activity
> >> waiting_resource - true for waits other heavy wait locks, false
> >> otherwise
> >> wait_event - description code for the wait event
> >>
> >> 3. Add new view 'pg_stat_wait_event' with following info:
> >> pid - process id of this backend
> >> waiting - true for any form of wait, false otherwise
> >> wait_event_type - Heavy Weight Lock, Light Weight Lock, I/O wait, etc
> >> wait_event - Lock (Relation), Lock (Relation Extension), etc
> >>
> >> Do you think 2nd or 3rd could be viable way to proceed for this feature?
> >
> > 3) sounds best to me. Keeping 'waiting' even makes sense in that case,
> > because it'll tell whether wait_event_type is currently being blocked
> > on. We can leave the former contents in until the next thing is being
> > blocked...
>
> So, that's still redefining the "waiting" column, because it will now
> indicate whether we are waiting on some wait event, not whether we are
> waiting on specifically a heavyweight lock. But that doesn't bother
> me, because I think it's going to be darn confusing if we keep
> "waiting" around with the specific meaning of "waiting for a
> heavyweight lock" while also now having a notion of "waiting for
> something else". I like the idea of indicating both the most recent
> wait event and whether or not we are still waiting for it - we refined
> current_query to query not too long ago, and I certainly think that
> was a significant improvement even if it broke some people's scripts.
>
> I am pretty unconvinced that it's a good idea to try to split up the
> wait event into two columns. I'm only proposing ~20 wait states, so
> there's something like 5 bits of information here. Spreading that
> over two text columns is a lot, and note that Amit's text would
> basically recapitulate the contents of the first column in the second
> one, which I cannot get excited about.
>
There is an advantage in splitting the columns which is if wait_event_type
column indicates Heavy Weight Lock, then user can go and check further
details in pg_locks, I think he can do that even by seeing wait_event
column, but that might not be as straightforward as with wait_event_type
