A few thoughts on LWLock data structures...

In lwlock.c we hold a list of lwlocks held:
held_lwlocks[MAX_SIMUL_LWLOCKS]
where
#define MAX_SIMUL_LWLOCKS 100

The code for LWLockRelease assumes that the last acquired lock will
always be the first one to be released, and uses an O(N) loop to search
for the lock to release.

Setting MAX_SIMUL_LWLOCKS to this fairly high number doesn't seem to
match the optimistic use of the O(N) algorithm.

Any thoughts on reducing the size of that array and/or reducing the lock
release time?

Best Regards, Simon Riggs


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

"Simon Riggs" <simon@2ndquadrant.com> writes:
> A few thoughts on LWLock data structures...

> In lwlock.c we hold a list of lwlocks held:
> held_lwlocks[MAX_SIMUL_LWLOCKS]
> where
> #define MAX_SIMUL_LWLOCKS 100

> The code for LWLockRelease assumes that the last acquired lock will
> always be the first one to be released, and uses an O(N) loop to search
> for the lock to release.

> Setting MAX_SIMUL_LWLOCKS to this fairly high number doesn't seem to
> match the optimistic use of the O(N) algorithm.

So? The search only examines the actually-in-use array entries.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org