Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id C0461633155
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 12 Mar 2009 14:53:32 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
	with ESMTP id 89785-10
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 12 Mar 2009 14:53:27 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by mail.postgresql.org (Postfix) with ESMTP id 47DCC632F38
	for <pgsql-performance@postgresql.org>;
	Thu, 12 Mar 2009 14:53:29 -0300 (ADT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	n2CHrSfk016088
	for <pgsql-performance@postgresql.org>; Thu, 12 Mar 2009 17:53:28 GMT
MIME-version: 1.0
Content-type: multipart/alternative;
	boundary="Boundary_(ID_Dbg9vFaQDZxjxh+V7W/geA)"
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19
	2009)) id <0KGE00700LE4FK00@mail-amer.sun.com> for
	pgsql-performance@postgresql.org;
	Thu, 12 Mar 2009 11:53:28 -0600 (MDT)
Received: from [129.148.169.151] ([unknown] [129.148.169.151])
	by mail-amer.sun.com
	(Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19
	2009)) with ESMTPSA id <0KGE00I3VN0UVC80@mail-amer.sun.com>; Thu,
	12 Mar 2009 11:53:19 -0600 (MDT)
Date: Thu, 12 Mar 2009 13:49:37 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <49B8E044.EE98.0025.0@wicourts.gov>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>,
	Scott Carey <scott@richrelevance.com>
Message-id: <49B94B31.2010201@sun.com>
Organization: Sun Microsystems
References: <49B7F470.EE98.0025.0@wicourts.gov>
	<C5DDBB25.3333%scott@richrelevance.com>
	<49B8E044.EE98.0025.0@wicourts.gov>
User-Agent: Thunderbird 2.0.0.17 (X11/20081023)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200903/132
X-Sequence-Number: 33054

This is a multi-part message in MIME format.

--Boundary_(ID_Dbg9vFaQDZxjxh+V7W/geA)
Content-type: text/plain; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT



On 03/12/09 11:13, Kevin Grittner wrote:
>>>> 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
>
>   

Every user has a think time (200ms) to wait before doing the next 
transaction which results in idle time and theoretically allows other 
users to run in between ..

-Jignesh


--Boundary_(ID_Dbg9vFaQDZxjxh+V7W/geA)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=US-ASCII" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 03/12/09 11:13, Kevin Grittner wrote:
<blockquote cite="mid:49B8E044.EE98.0025.0@wicourts.gov" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">Scott Carey <a class="moz-txt-link-rfc2396E" href="mailto:scott@richrelevance.com">&lt;scott@richrelevance.com&gt;</a> wrote: 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">"Kevin Grittner" <a class="moz-txt-link-rfc2396E" href="mailto:Kevin.Grittner@wicourts.gov">&lt;Kevin.Grittner@wicourts.gov&gt;</a> wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">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.
      </pre>
    </blockquote>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!----> 
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

  </pre>
</blockquote>
<br>
Every user has a think time (200ms) to wait before doing the next
transaction which results in idle time and theoretically allows other
users to run in between ..<br>
<br>
-Jignesh<br>
<br>
</body>
</html>

--Boundary_(ID_Dbg9vFaQDZxjxh+V7W/geA)--