2010/12/7 Віталій Тимчишин <tivv00(at)gmail(dot)com>:
> 2010/12/7 Robert Haas <robertmhaas(at)gmail(dot)com>
>> On Tue, Dec 7, 2010 at 1:08 PM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
>> > I'm not very familiar with PostgreSQL code but if we're
>> > brainstorming... if you're only trying to protect against a small
>> > number of expensive operations (like DROP, etc.) that don't really
>> > happen often, wouldn't an atomic reference counter be good enough for
>> > the purpose (e.g. the expensive operations would spin-wait until the
>> > counter is 0)?
>> No, because (1) busy-waiting is only suitable for locks that will only
>> be held for a short time, and an AccessShareLock on a table might be
>> held while we read 10GB of data in from disk, and (2) that wouldn't
>> allow for deadlock detection.
> What can be done, is that number of locks can be increased - one could use
> spin locks for hash table manipulations, e.g. a lock preventing rehashing
> (number of baskets being changed) and a lock for required basket.
> In this case only small range of code can be protected by partition lock.
> As for me, this will make locking process more cpu-intensive (more locks
> will be acquired/freed during the exection), but will decrease contention
> (since all but one lock can be spin locks working on atomic counters, hash
> searches can be done in parallel), won't it?
For what it's worth, this is pretty much the opposite of what I had in
mind. I proposed atomic reference counters (as others pointed, this
probably won't work) as poor-man's shared-exclusive locks, so that
most operations would not have to contend on them.
In response to
pgsql-performance by date
|Next:||From: Robert Haas||Date: 2010-12-08 04:23:48|
|Subject: Re: Performance under contention|
|Previous:||From: Kevin Grittner||Date: 2010-12-07 22:39:59|
|Subject: Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows|