Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 41A58650760
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue,  9 Dec 2008 19:29:02 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 93878-01-8
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue,  9 Dec 2008 19:28:59 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.emproshunts.com (mail.emproshunts.com [66.64.191.19])
	by mail.postgresql.org (Postfix) with ESMTP id CE220650790
	for <pgsql-performance@postgresql.org>;
	Tue,  9 Dec 2008 19:21:26 -0400 (AST)
Received: from [192.168.1.42] by mail.emproshunts.com (GMS
	15.01.3664/KX5895.00.ca608199) with ESMTP id ulfljaaa for
	pgsql-performance@postgresql.org; Tue, 9 Dec 2008 18:21:17 -0500
Message-ID: <493EFD07.4080201@emproshunts.com>
Date: Tue, 09 Dec 2008 18:19:35 -0500
From: justin <justin@emproshunts.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Need help with 8.4 Performance Testing
References: <C5642B9E.F8A%scott@richrelevance.com>
	<22285.1228862315@sss.pgh.pa.us>
In-Reply-To: <22285.1228862315@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------010403050004010703090402"
X-Originating-IP: [192.168.1.42]
X-DNSBL: 0
X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5
	tests=HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200812/98
X-Sequence-Number: 32134

This is a multi-part message in MIME format.
--------------010403050004010703090402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Scott Carey <scott@richrelevance.com> writes:
>   
>> Which brings this back around to the point I care the most about:
>> I/O per second will diminish as the most common database performance limiting factor in Postgres 8.4's lifetime, and become almost irrelevant in 8.5's.
>> Becoming more CPU efficient will become very important, and for some, already is.  The community needs to be proactive on this front.
>> This turns a lot of old assumptions on their head, from the database down through the OS and filesystem.  We're bound to run into many surprises due to this major shift in something that has had its performance characteristics taken for granted for decades.
>>     
>
> Hmm ... I wonder whether this means that the current work on
> parallelizing I/O (the posix_fadvise patch in particular) is a dead
> end.  Because what that is basically going to do is expend more CPU
> to improve I/O efficiency.  If you believe this thesis then that's
> not the road we want to go down.
>
> 			regards, tom lane
>   

What does the CPU/ Memory/Bus performance road map look like?

Is the IO performance for storage device for what ever it be, going to 
be on par with the above to cause this problem?

Once IO performance numbers start jumping up I think DBA will have the 
temptation start leaving more and more data in the production database  
instead of moving it out of the production database. Or start 
consolidating databases onto fewer servers .  Again pushing more load 
onto the IO. 

--------------010403050004010703090402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane wrote:
<blockquote cite="mid:22285.1228862315@sss.pgh.pa.us" type="cite">
  <pre wrap="">Scott Carey <a class="moz-txt-link-rfc2396E"
 href="mailto:scott@richrelevance.com">&lt;scott@richrelevance.com&gt;</a> writes:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Which brings this back around to the point I care the most about:
I/O per second will diminish as the most common database performance limiting factor in Postgres 8.4's lifetime, and become almost irrelevant in 8.5's.
Becoming more CPU efficient will become very important, and for some, already is.  The community needs to be proactive on this front.
This turns a lot of old assumptions on their head, from the database down through the OS and filesystem.  We're bound to run into many surprises due to this major shift in something that has had its performance characteristics taken for granted for decades.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hmm ... I wonder whether this means that the current work on
parallelizing I/O (the posix_fadvise patch in particular) is a dead
end.  Because what that is basically going to do is expend more CPU
to improve I/O efficiency.  If you believe this thesis then that's
not the road we want to go down.

			regards, tom lane
  </pre>
</blockquote>
<br>
What does the CPU/ Memory/Bus performance road map look like?<br>
<br>
Is the IO performance for storage device for what ever it be, going to
be on par with the above to cause this problem?<br>
<br>
Once IO performance numbers start jumping up I think DBA will have the
temptation start leaving more and more data in the production database&nbsp;
instead of moving it out of the production database. Or start
consolidating databases onto fewer servers .&nbsp; Again pushing more load
onto the IO.&nbsp; <br>
</body>
</html>

--------------010403050004010703090402--