2010/12/7 ÐÑÑÐÐÑÐ ÐÐÐÑÐÑÐÐ <tivv00@xxxxxxxxx>: > > > 2010/12/7 Robert Haas <robertmhaas@xxxxxxxxx> >> >> On 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)? >> >> 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. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
