Skip site navigation (1) Skip section navigation (2)

Re: LWLockRelease

From: Neil Conway <neilc(at)samurai(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LWLockRelease
Date: 2005-02-03 14:00:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 

> 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...


In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2005-02-03 14:03:14
Subject: Re: LWLockRelease
Previous:From: Mark Cave-AylandDate: 2005-02-03 11:21:23
Subject: Re: [NOVICE] Last ID Problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group