Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id C2DF0635049
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 16 Mar 2009 16:43:27 -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 21175-02
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 16 Mar 2009 16:43:19 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by mail.postgresql.org (Postfix) with ESMTP id 186B6632C53
	for <pgsql-performance@postgresql.org>;
	Mon, 16 Mar 2009 16:43:13 -0300 (ADT)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	n2GJhBnu004356
	for <pgsql-performance@postgresql.org>; Mon, 16 Mar 2009 19:43:11 GMT
MIME-version: 1.0
Content-type: multipart/alternative;
	boundary="Boundary_(ID_vuHqi+SSRvyLoNI4p94Spg)"
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 <0KGM00C006CBBO00@mail-amer.sun.com> for
	pgsql-performance@postgresql.org;
	Mon, 16 Mar 2009 13:43:11 -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 <0KGM00F826RS7N20@mail-amer.sun.com>; Mon,
	16 Mar 2009 13:43:04 -0600 (MDT)
Date: Mon, 16 Mar 2009 15:39:20 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <87fxhd33qb.fsf@oxford.xeocode.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: decibel <decibel@decibel.org>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49BEAAE8.4010402@sun.com>
Organization: Sun Microsystems
References: <C5DEE151.33BA%scott@richrelevance.com> <49BA53CF.4020702@sun.com>
	<49BA742D.3050203@sun.com> <49BA8CF6.6090604@sun.com>
	<49BABBCE.8090501@sun.com>
	<D4B5954C-4E01-40B7-BC6E-F98842593889@decibel.org>
	<49BD6840.4000403@sun.com> <87fxhd33qb.fsf@oxford.xeocode.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20081023)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200903/217
X-Sequence-Number: 33139

This is a multi-part message in MIME format.

--Boundary_(ID_vuHqi+SSRvyLoNI4p94Spg)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT



On 03/16/09 11:08, Gregory Stark wrote:
> "Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
>
>   
>> Generally when there is dead constant.. signs of classic bottleneck ;-)  We
>> will be fixing one to get to another.. but knocking bottlenecks is the name of
>> the game I think
>>     
>
> Indeed. I think the bottleneck we're interested in addressing here is why you
> say you weren't able to saturate the 64 threads with 64 processes when they're
> all RAM-resident.
>
> From what I see you still have 400+ processes? Is that right?
>
>   

Any one claiming they run CPU intensive are not always telling the 
truth.. They *Think* they are running CPU intensive for the right part 
but there could be memory misses, they could be doing statistics where 
they are not really stressing the intended stuff to test, they could be 
parsing through the results where they are not stressing the backend 
while still claiming to be cpu intensive (though from a different 
perspective)

So yes a single process specially a client cannot claim to keep the 
backend 100% active but so can neither a connection pooler since it 
still has to some other stuff within the process.

-Jignesh


--Boundary_(ID_vuHqi+SSRvyLoNI4p94Spg)
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/16/09 11:08, Gregory Stark wrote:
<blockquote cite="mid:87fxhd33qb.fsf@oxford.xeocode.com" type="cite">
  <pre wrap="">"Jignesh K. Shah" <a class="moz-txt-link-rfc2396E" href="mailto:J.K.Shah@Sun.COM">&lt;J.K.Shah@Sun.COM&gt;</a> writes:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Generally when there is dead constant.. signs of classic bottleneck ;-)  We
will be fixing one to get to another.. but knocking bottlenecks is the name of
the game I think
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Indeed. I think the bottleneck we're interested in addressing here is why you
say you weren't able to saturate the 64 threads with 64 processes when they're
all RAM-resident.

From what I see you still have 400+ processes? Is that right?

  </pre>
</blockquote>
<br>
Any one claiming they run CPU intensive are not always telling the
truth.. They *Think* they are running CPU intensive for the right part
but there could be memory misses, they could be doing statistics where
they are not really stressing the intended stuff to test, they could be
parsing through the results where they are not stressing the backend
while still claiming to be cpu intensive (though from a different
perspective)<br>
<br>
So yes a single process&nbsp; specially a client cannot claim to keep the
backend 100% active but so can neither a connection pooler since it
still has to some other stuff within the process.<br>
<br>
-Jignesh<br>
<br>
</body>
</html>

--Boundary_(ID_vuHqi+SSRvyLoNI4p94Spg)--