Manfred Spraul <manfred@colorfullife.com> writes:
> Tom Lane wrote:
>> I'd be more interested in asking why you're seeing long series
>> of semops in the first place.
> I couldn't figure out what exactly causes the long series of semops. I
> tried to track it down (enable LOCK_DEBUG):
> - postgres 7.3.3.
> - pgbench -c 30 -t 300
Oh, pgbench ;-). Are you aware that you need a "scale factor" (-s)
larger than the number of clients to avoid unreasonable levels of
contention in pgbench? For example, with -s = 1 there is only one
row in the "branches" table, and *every* transaction will want to
update that row. So you get scenarios with multiple transactions
blocked waiting for the guy who has managed to lock the row, and when
he commits they are all released. One of them succeeds in locking
the updated row, and the others all promptly start to wait for *him*.
Etc. I don't think this level of contention is common in real apps,
but in pgbench with small -s it's a major factor.
We could avoid this spinning if we had real per-row locks (so that procs
wouldn't get awoken till they actually had lock on the desired row), but
I see no very practical way to do that.
regards, tom lane
