2010/12/7 Robert Haas <robertmhaas@xxxxxxxxx>
No, because (1) busy-waiting is only suitable for locks that will onlyOn Tue, Dec 7, 2010 at 1:08 PM, Ivan Voras <ivoras@xxxxxxxxxxx> 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)?
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 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
--
Best regards,
Vitalii Tymchyshyn
