Skip site navigation (1) Skip section navigation (2)

Re: Performance under contention

From: Ivan Voras <ivoras(at)freebsd(dot)org>
To: Віталій Тимчишин <tivv00(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jignesh Shah <jkshah(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance under contention
Date: 2010-12-07 22:43:14
Message-ID: AANLkTi=RYsRBd4WqqQn3Ku3bXQv4CgY1rmkJczg-Z6LA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
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 HaasDate: 2010-12-08 04:23:48
Subject: Re: Performance under contention
Previous:From: Kevin GrittnerDate: 2010-12-07 22:39:59
Subject: Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group