Re: semtimedop instead of setitimer/semop/setitimer

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Spraul <manfred(at)colorfullife(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: semtimedop instead of setitimer/semop/setitimer
Date: 2003-09-20 14:42:05
Message-ID: 23323.1064068925@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Manfred Spraul <manfred(at)colorfullife(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-09-20 15:12:32 Re: 7.4beta2 vs 7.3.3
Previous Message Christopher Browne 2003-09-20 13:54:34 Re: why postgresql is so slow?

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-09-20 15:37:32 Re: pgsql-server/src/backend catalog/index.c comma ...
Previous Message Manfred Spraul 2003-09-20 10:34:00 Re: semtimedop instead of setitimer/semop/setitimer