On Wed, Jul 6, 2011 at 2:02 PM, Jeff Davis <pg...@j-davis.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
