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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers