To: Simon Riggs <simon@2ndQuadrant.com>
cc: Matthew Wakeling <matthew@flymine.org>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Proposal of tunable fix for scalability of 8.4 
In-reply-to: <1237362833.3953.186.camel@ebony.2ndQuadrant> 
References: <alpine.GSO.2.01.0903121613270.1925@westnet.com>
	<C5DED7A7.33B2%scott@richrelevance.com>
	<603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com>
	<12292.1236964604@sss.pgh.pa.us>
	<49BB699D.1070809@enterprisedb.com>
	<alpine.DEB.2.00.0903161543590.21772@aragorn.flymine.org>
	<1237362833.3953.186.camel@ebony.2ndQuadrant>
Comments: In-reply-to Simon Riggs <simon@2ndQuadrant.com>
	message dated "Wed, 18 Mar 2009 07:53:53 -0000"
Date: Wed, 18 Mar 2009 16:26:45 -0400
Message-ID: <15144.1237408005@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Simon Riggs <simon@2ndQuadrant.com> writes:
> On Mon, 2009-03-16 at 16:26 +0000, Matthew Wakeling wrote:
>> One possibility would be for the locks to alternate between exclusive
>> and 
>> shared - that is:
>> 
>> 1. Take a snapshot of all shared waits, and grant them all -
>> thundering
>> herd style.
>> 2. Wait until ALL of them have finished, granting no more.
>> 3. Take a snapshot of all exclusive waits, and grant them all, one by
>> one.
>> 4. Wait until all of them have been finished, granting no more.
>> 5. Back to (1)

> I agree with that, apart from the "granting no more" bit.

> Currently we queue up exclusive locks, but there is no need to since for
> ProcArrayLock commits are all changing different data.

> The most useful behaviour is just to have two modes:
> * exclusive-lock held - all other x locks welcome, s locks queue
> * shared-lock held - all other s locks welcome, x locks queue

My goodness, it seems people have forgotten about the "lightweight"
part of the LWLock design.

			regards, tom lane