On 8/8/23 3:04 PM, Andres Freund wrote: > On 2023-08-08 16:44:37 -0400, Robert Haas wrote: >> On Mon, Aug 7, 2023 at 6:05 PM Andres Freund <and...@anarazel.de> wrote: >>> I think the biggest flaw of the locking scheme is that the LockHash locks >>> protect two, somewhat independent, things: >>> 1) the set of currently lockable objects, i.e. the entries in the hash >>> table [partition] >>> 2) the state of all the locks [in a partition] >>> >>> It'd not be that hard to avoid the shared hashtable lookup in a number of >>> cases, e.g. by keeping LOCALLOCK entries around for longer, as I suggest >>> above. But we can't, in general, avoid the lock on the partition anyway, as >>> the each lock's state is also protected by the partition lock. >> >> Yes, and that's a huge problem. The main selling point of the whole >> fast-path mechanism is to ease the pressure on the lock manager >> partition locks, and if we did something like what you described in >> the previous email without changing the locking regimen, we'd bring >> all of that contention back. I'm pretty sure that would suck. > > Yea - I tried to outline how I think we could implement the fastpath locking > scheme in a less limited way in the earlier email, that I had quoted above > this bit. Here I was pontificating on what we possibly should do in addition > to that. I think even if we had "unlimited" fastpath locking, there's still > enough pressure on the lock manager locks that it's worth improving the > overall locking scheme.
Has anyone considered whether increasing NUM_LOCK_PARTITIONS to something bigger than 16 might offer cheap/easy/small short-term improvements while folks continue to think about the bigger long-term ideas? cf. https://www.postgresql.org/message-id/flat/VI1PR05MB620666631A41186ACC3FC91ACFC70%40VI1PR05MB6206.eurprd05.prod.outlook.com I haven't looked deeply into it myself yet. Didn't see a mention in this thread or in Matt's gitlab research ticket. Maybe it doesn't actually help. Anyway Alexander Pyhalov's email about LWLock optimization and NUM_LOCK_PARTITIONS is out there, and I wondered about this. -Jeremy -- Jeremy Schneider Performance Engineer Amazon Web Services
