On Mon, Feb 1, 2016 at 8:40 AM, Alexander Korotkov <aekorot...@gmail.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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers