Re: RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Feb 2, 2016 at 10:09 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Mon, Feb 1, 2016 at 8:40 AM, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
wrote:
> > 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.
> > 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.
> > And then we save 16 bits for lock number. It's certainly not enough for
some
> > tranches. For instance, number of buffers could be easily more than
2^16.
> > However, we could expose at least lower 16 bits. It would be at least
> > something. Using this information user at least can make a conclusion
like
> > "It MIGHT be a high concurrency for single buffer content. Other way it
is
> > coincidence that a lot of different buffers have the same 16 lower
bits.".
> >
> > Any thoughts?
>
> Meh. I think that's trying to be too clever. That seems hard to
> document, hard to explain, and likely incomprehensible to users.
>

So, let's leave adding any additional column, but Alexander has brought up
a good point about storing the wait_type and actual wait_event
information into four bytes. Currently I have stored wait_type (aka
classId)
in first byte and then two bytes for wait_event (eventId) and remaining
one-byte can be used in future if required, however Alexandar is proposing
to
combine both these (classId and eventId) into two-bytes which sounds
reasonable to me apart from the fact that it might add operation or two
extra
in this path. Do you or anyone else have any preference over this point?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com