Hi, On 2021-12-01 19:56:11 +0530, Ashkil Dighin wrote: > The performance bottleneck in LWLockRelease()method goes through an array > one by one to see which lock was released with O(N). As soon as the lock is > found it performs an array to remove the lock. > As linear search and compaction delays the release of the lock forcing the > other Postgres instances WAiting for the lock to be released > Is any possible solution like > 1. LWLockRelease() releases the lock first and then remove held lock from > the array You currently can't really - we don't know the to-be-released lockmode without the lookup in the array. You could try to reason it based on the current state of the lock, but that doesn't strike me as a great idea either. > 2. Binary search (like non-linear structure) to reduce on high searching > and remove all held locks That'd likely lead to considerably worse performance. Due to the unpredictable branches binary search is worse than linear search at low-ish array values (obviously depends on the cost of a comparison etc). Do you have a workload where this is a significant issue? Most of the time we do not hold enough lwlocks for it to be a problem. I've seen it become a bottleneck during my AIO work (*) - but IIRC I worked around it. IIRC I observed the shifting of the locks to be the bigger issue than the search for the locks themselves. It might be worth experimenting with not shifting allt he subsequent locks, but instead just swapping in the currently-last lock. Greetings, Andres Freund (*) IIRC the issue is when writing back we try to write back multiple buffers at once (using conditional lock acquisition to avoid deadlocks). Those then are likely released in FIFO order. I think it's now not a problem anymore because I ended up introducing the concept of locks that are owned by the AIO subsystem for other reasons.
