On Tue, Apr 13, 2021 at 4:46 PM Andres Freund <and...@anarazel.de> wrote: > I still don't like the two bytes, fwiw ;). Especially because it's 4 > bytes due to padding right now.
I'm not surprised by that disclosure. But I think it's entirely worth it. Making wait states visible in pg_stat_activity isn't the most useful thing I've ever done to PostgreSQL, but it's far from the least useful. If we can get the same benefit with less overhead, that's great. > I'd like to move the LWLock->waiters list to outside of the lwlock > itself - at most TotalProcs LWLocks can be waited for, so we don't need > millions of empty proclist_heads. That way we could also remove the > proclist indirection - which shows up a fair bit in contended workloads. > > And if we had a separate "lwlocks being waited for" structure, we could > also add more information to it if we wanted to... > > The difficulty of course is having space to indicate which of these > "waiting for" lists are being used - there's not enough space in ->state > right now to represent that. Two possibile approaches: > > - We could make it work if we restricted MAX_BACKENDS to be 2**14 - but > while I personally think that's a sane upper limit, I already had a > hard time getting consensus to lower the limit to 2^18-1. > > - Use a 64bit integer. Then we can easily fit MAX_BACKENDS lockers, as > well as an offset to one of MAX_BACKENDS "wait lists" into LWLock. I'd rather not further reduce MAX_BACKENDS. I still think some day we're going to want to make that bigger again. Maybe not for a while, admittedly. But, do you need to fit this into "state"? If you just replaced "waiters" with a 32-bit integer, you'd save 4 bytes and have bits left over (and maybe restrict the tranche ID to 2^14 and squeeze that in too, as you mention). -- Robert Haas EDB: http://www.enterprisedb.com
