On Thu, Jan 28, 2016 at 9:16 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Jan 28, 2016 at 2:12 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > > > On Tue, Jan 26, 2016 at 3:10 AM, andres@anarazel.de <andres@anarazel.de> wrote: > > > 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. > > > > +1 for splitting it into two fields. > > > > I will take care of this.
>
As discussed, I have added a new field wait_event_type along with
wait_event in pg_stat_activity. Changed the code return NULL, if
backend is not waiting. Updated the docs as well.
I wonder if we can use 4-byte wait_event_info more efficiently.
LWLock number in the tranche would be also useful information to expose. Using lwlock number user can determine if there is high concurrency for single lwlock in tranche or it is spread over multiple lwlocks.
So what you are suggesting is that have an additional information
like sub_wait_event and it will display lock number for the LWLocks
which belong to tranche and otherwise it will be NULL for HWLocks
or Individual LWLocks. I see the value in have one more field, but
just displaying some number and that too is not exact in some cases
like where LWLocks are more doesn't sound to be very informative.
Any body else have an opinion on this matter?
I think it would be enough to have 6 bits for event class id and 10 bit for event id. So, it would be maximum 64 event classes and maximum 1024 events per class. These limits seem to be fair enough for me.
I also think those are fair limits, let me try to shrink those into