Setting MAX_SIMUL_LWLOCKS to this fairly high number doesn't seem to match the optimistic use of the O(N) algorithm.
How so? The algorithm is O(n) for the number of locks _currently held_, not the maximum number of locks we might be able to hold. In other words, in LWLockRelease() we search the array beginning from the most-recently acquired lock back toward the least-recently acquired lock -- we're iterating only over the locks we currently hold. So I don't see how changing MAX_SIMUL_LWLOCKS will affect performance to a significant degree.
Any thoughts on reducing the size of that array and/or reducing the lock release time?
Do we have any evidence that this is actually a performance problem? Given the short period of time we ought to hold an LWLock for, I think the heuristic that we release the most-recently acquired lock is actually quite a good one. Furthermore, I would guess/hope that a backend is unlikely to be holding very many LWLocks simultaneously, so even if the heuristic is wrong we're at best searching through (and then subsequently re-arranging) a relatively small number of locks.
Perhaps some data on the average value of num_held_locks and the number of entries we needed to search through to find the right lock would help verify whether this is indeed a problem.
I wonder whether the direction of the linear array search (from 0 .. n or n .. 0 -- forward or backward) has any effect on the way the processor does prefetching and so forth. It would be easy to reorder the array so that the first lock we acquire is placed at the end of the array; then, LWLockRelease() would search forward through the array rather than backward. My guess is it won't make a difference, but I thought I'd mention it...
-Neil
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
