On 11/08/2020 03:41, Andres Freund wrote:
On 2020-08-10 18:27:17 -0400, Robert Haas wrote:
On Tue, Jun 2, 2020 at 8:25 AM Drouvot, Bertrand <bdrou...@amazon.com> wrote:
the patch adds into the LWLock struct:
last_holding_pid: last pid owner of the lock
last_mode: last holding mode of the last pid owner of the
lock
nholders: number of holders (could be >1 in case of
LW_SHARED)
There's been significant work done over the years to get the size of
an LWLock down; I'm not very enthusiastic about making it bigger
again. See for example commit 6150a1b08a9fe7ead2b25240be46dddeae9d98e1
which embeds one of the LWLocks associated with a BufferDesc into the
structure to reduce the number of cache lines associated with common
buffer operations. I'm not sure whether this patch would increase the
space usage of a BufferDesc to more than one cache line again, but at
the very least it would make it a lot tighter, since it looks like it
adds 12 bytes to the size of each one.
+many. If anything I would like to make them *smaller*. We should strive
to make locking more and more granular, and that requires the space
overhead to be small. I'm unhappy enough about the tranche being in
there, and requiring padding etc.
I spent a *LOT* of sweat getting where we are, I'd be unhappy to regress
on size or efficiency.
That seems to be the consensus, so I'm marking this as Returned with
Feeback in the commitfest.
- Heikki
