Simon Riggs wrote:
> 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