Re: Performance under contention

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.
>

As far as I understand this thread, the talk is about contention - where
large number of processors want to get single partition lock to get
high-level shared lock.
As far as I can see from the source, there is a lot of code executed under
the partition lock protection, like two hash searches (and possibly
allocations).
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?
The thing I am not sure in is how much spinlocks on atomic counters cost
today.

--
Best regards,
Vitalii Tymchyshyn