Manfred Spraul <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster