On 7 December 2010 18:37, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 6, 2010 at 9:59 PM, Jignesh Shah <jkshah@gmail.com> wrote:
>> That's exactly what I concluded when I was doing the sysbench simple
>> read-only test. I had also tried with different lock partitions and it
>> did not help since they all go after the same table. I think one way
>> to kind of avoid the problem on the same table is to do more granular
>> locking (Maybe at page level instead of table level). But then I dont
>> really understand on how to even create a prototype related to this
>> one. If you can help create a prototype then I can test it out with my
>> setup and see if it helps us to catch up with other guys out there.
>
> We're trying to lock the table against a concurrent DROP or schema
> change, so locking only part of it doesn't really work. I don't
> really see any way to avoid needing some kind of a lock here; the
> trick is how to take it quickly. The main obstacle to making this
> faster is that the deadlock detector needs to be able to obtain enough
> information to break cycles, which means we've got to record in shared
> memory not only the locks that are granted but who has them.
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)?