Hi hackers, Following up on the Discord discussion about the PROCLOCK hash table being a "weird allocator" that we never actually use for lookups - I took a stab at replacing it with a simpler partitioned free list approach as was suggested. I was doing this mostly to educate myself on Lock Manager internals.
The current implementation uses LockMethodProcLockHash purely as an allocator. We never do hash lookups by key; we only allocate entries, link them to the lock's procLocks list, and free them later. Using a full hash table for this adds unnecessary complexity and maybe even overhead (I did not measure this). The attached patch replaces this with: - ProcLockArray: A fixed-size array of all PROCLOCK structs (allocated at startup) - ProcLockFreeList: Partitioned free lists, one per lock partition to reduce contention - ProcLockAlloc/Free: Simple push/pop operations on the free lists - PROCLOCK lookup: Linear traversal of lock->procLocks (see LockRefindAndRelease() and FastPathGetRelationLockEntry()) The last point bothers me most. It seems like this traversals are expected to be short. But I'm not 100% sure. This patch removes the proclock_hash() function and ProcLockHashCode() entirely, and eliminates all hash_search() calls for PROCLOCKs. The allocation/deallocation is now just dlist operations instead of hash table management. Would appreciate your thoughts on this approach. Is this the direction worth working on? Best regards, Andrey Borodin.
v1-0001-Replace-PROCLOCK-hash-table-with-partitioned-free.patch
Description: Binary data
