Message-Id: <49B8E044.EE98.0025.0@wicourts.gov>
Date: Thu, 12 Mar 2009 10:13:24 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>,
	"Scott Carey" <scott@richrelevance.com>,
	"Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
References: <49B7F470.EE98.0025.0@wicourts.gov>
	<C5DDBB25.3333%scott@richrelevance.com>
In-Reply-To: <C5DDBB25.3333%scott@richrelevance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>>> Scott Carey <scott@richrelevance.com> wrote: 
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
> 
>> I'm a lot more interested in what's happening between 60 and 180
>> than over 1000, personally.  If there was a RAID involved, I'd put
>> it down to better use of the numerous spindles, but when it's all
>> in RAM it makes no sense.
> 
> If there is enough lock contention and a common lock case is a short
> lived shared lock, it makes perfect sense sense.  Fewer readers are
> blocked waiting on writers at any given time.  Readers can 'cut' in
> line ahead of writers within a certain scope (only up to the number
> waiting at the time a shared lock is at the head of the queue). 
> Essentially this clumps up shared and exclusive locks into larger
> streaks, and allows for higher shared lock throughput.
 
You misunderstood me.  I wasn't addressing the affects of his change,
but rather the fact that his test shows a linear improvement in TPS up
to 1000 connections for a 64 thread machine which is dealing entirely
with RAM -- no disk access.  Where's the bottleneck that allows this
to happen?  Without understanding that, his results are meaningless.
 
-Kevin