Re: reducing the overhead of frequent table locks, v4

On Wed, Jul 6, 2011 at 2:02 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Thu, 2011-06-30 at 19:25 -0400, Robert Haas wrote:
>> I'm really hurting
>> for is some code review.
>
> I'm trying to get my head into this patch. I have a couple questions:
>
> Does this happen to be based on some academic research? I don't
> necessarily expect it to be; just thought I'd ask.

I did spend some time Googling around for papers and some of the other
approaches I've tried (mostly unsuccessfully, thus far) were based on
those papers, but I don't remember running across anything that
resembled the approach taken in the patch. I think that the patch
basically came out what I know about how PostgreSQL works: namely, we
take tons of locks, but mostly of a sort that don't conflict with each
other.

> Here is my high-level understanding of the approach, please correct me
> where I'm mistaken:
>
> Right now, concurrent activity on the same object, even with weak locks,
> causes contention because everything has to hit the same global lock
> partition. Because we expect an actual conflict to be rare, this patch
> kind of turns the burden upside down such that:
>  (a) those taking weak locks need only acquire a lock on their own lock
> in their own PGPROC, which means that it doesn't contend with anyone
> else taking out a weak lock; and
>  (b) taking out a strong lock requires a lot more work, because it needs
> to look at every backend in the proc array to see if it has conflicting
> locks.
>
> Of course, those things both have some complexity, because the
> operations need to be properly synchronized. You force a valid schedule
> by using the memory synchronization guarantees provided by taking those
> per-backend locks rather than a centralized lock, thus still avoiding
> lock contention in the common (weak locks only) case.

You got it. That's a very good summary.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company