Re: Performance under contention

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.