On 2016-01-26 13:22:09 +0530, Amit Kapila wrote:
> @@ -633,9 +633,11 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
> <entry>Time when the <structfield>state</> was last changed</entry>
> </row>
> <row>
> - <entry><structfield>waiting</></entry>
> - <entry><type>boolean</></entry>
> - <entry>True if this backend is currently waiting on a lock</entry>
> + <entry><structfield>wait_event</></entry>
> + <entry><type>text</></entry>
> + <entry>Wait event name if backend is currently waiting, otherwise
> + <literal>process not waiting</>
> + </entry>
> </row>
> <row>
I still think this is a considerable regression in pg_stat_activity
usability. There are lots of people out there that have queries that
automatically monitor pg_stat_activity.waiting, and automatically go to
pg_locks to understand what's going on, if there's one. With the above
definition, that got much harder. Not only do I have to write
WHERE wait_event <> 'process not waiting', but then also parse the wait
event name, to know whether the process is waiting on a heavyweight
lock, or something else!
I do think there's a considerable benefit in improving the
instrumentation here, but his strikes me as making live more complex for
more users than it makes it easier. At the very least this should be
split into two fields (type & what we're actually waiting on). I also
strongly suspect we shouldn't use in band signaling ("process not
waiting"), but rather make the field NULL if we're not waiting on
anything.
Greetings,
Andres Freund