I added some code to the backend to count the number of LWLockAcquire
calls and the number of resultant process blocks (IpcSemaphoreLocks)
across all PG processes.  Here are the results for a pgbench run with
scale factor 500, number of clients 10, proposed LWLock patch installed
on that 4-way Linux box.

LWLock		acquires	blocks		fraction

BufMgrLock	1238892		60273		0.0486507298457008
LockMgrLock	690150		83250		0.120625950880243
OidGenLock	10004		3		0.000299880047980808
XidGenLock	60019		29		0.000483180326230027
ShmemIndexLock	180		0		0
SInvalLock	817017		1940		0.00237449159564611
FreeSpaceLock	290		0		0
WALInsertLock	80039		6139		0.0767001086970102
WALWriteLock	10194		1180		0.115754365312929
ControlFileLock	141		0		0
CLogControlLock	25366		56		0.0022076795710794
buf cxt locks	930006		172		0.000184945043365312
buf io locks	31859		142		0.00445713926990803
clog buf locks	1880		2		0.00106382978723404

Interesting data, eh?  In particular, it seems my previous opinion
that BufMgrLock was the main issue is all wet: the LockMgrLock accounts
for more blockages despite being locked fewer times.  AFAICS this must
mean that the average time of holding LockMgrLock is larger than the
average time of holding BufMgrLock, and that we ought to look at how
to reduce that.  The WAL locks also seem to have disproportionately
large blocking percentages.

			regards, tom lane

Sun, 06 Jan 2002 23:20:18 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Further info on LWLock behavior