X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 4C66611F662C
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Thu,  6 Apr 2006 00:36:07 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 26562-04
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Thu,  6 Apr 2006 00:36:01 -0300 (ADT)
Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159])
	by postgresql.org (Postfix) with ESMTP id D180011F690C
	for <pgsql-performance@postgresql.org>;
	Thu,  6 Apr 2006 00:36:00 -0300 (ADT)
Received: from smtp.sw.oz.au (alt.aurema.com [203.217.18.57])
	by svr4.postgresql.org (Postfix) with ESMTP id 162CD5AF94B
	for <pgsql-performance@postgresql.org>;
	Thu,  6 Apr 2006 03:35:59 +0000 (GMT)
Received: from [192.41.203.74] (anthonyr.sw.oz.au [192.41.203.74])
	by smtp.sw.oz.au with ESMTP id k363ZlSU019781
	for <pgsql-performance@postgresql.org>;
	Thu, 6 Apr 2006 13:35:47 +1000 (EST)
Message-ID: <44348C93.2080106@aurema.com>
Date: Thu, 06 Apr 2006 13:35:47 +1000
From: Anthony Ransley <anthonyr@aurema.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3
References: <7583B3F1891CC0429FA4A44952AA539C66FA2C@wfm-exchprd2.wfm.pvt>
In-Reply-To: <7583B3F1891CC0429FA4A44952AA539C66FA2C@wfm-exchprd2.wfm.pvt>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.52 on 192.41.203.35
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.002 required=5 tests=[HTML_MESSAGE=0.001,
	MIME_HTML_ONLY=0.001]
X-Spam-Score: 0.002
X-Spam-Level: 
X-Archive-Number: 200604/86
X-Sequence-Number: 18170

<!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">
Hi Juan Casero,<br>
<br>
I've found that serial query clients are best served by PostgreSQL
running on fast single or dual core processors, ( such as the Athlon
FX60 ) rather than expensive n-way systems. I was orginally using an
8-way Xeon computer for a similar serial throughput problem. and i
wasn't supprised to find that at least 6 of the 8 processors were idle.
The point is, for this type client, you are better off spending the
money on the fastest single or dual core processors than a multiway box.<br>
<br>
Anthony.<br>
<br>
Juan Casero (FL FLC) wrote:
<blockquote
 cite="mid7583B3F1891CC0429FA4A44952AA539C66FA2C@wfm-exchprd2.wfm.pvt"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2838" name="GENERATOR">
  <div align="left" dir="ltr"><span class="812374617-05042006"><font
 face="Arial" size="2">Greetings -</font></span></div>
  <div><span class="812374617-05042006"></span>&nbsp;</div>
  <div><span class="812374617-05042006"><font face="Arial" size="2">I
am testing a Sun Microsystems Sun Fire T2000 demo server at our
company.&nbsp;&nbsp; I want to know if anyone here has any experience with this
hardware and postgresql 8.1.3.&nbsp; I installed the copy of postgresql
8.1.3 from blastwave.org onto this demo box and loaded our production
database into it.&nbsp; This box has a single Ultrasparc T1 cpu with six
execution piplelines that can each handle 4 threads.&nbsp; With the Unix top
utility the postgresql server appears to bounce around between the
available threads on the system.&nbsp; For example I run a single large
query and I can see the postgresql server sometimes running on cpu/0,
other times on cpu/1, cpu/3,....etc up to cpu/23.&nbsp;&nbsp; However, never is
the load for the postgres server reported to be higher than 4.16%.&nbsp; I
did the math and 4.16% x 24 threads = 98.84% cpu load.&nbsp; So I wonder if
the Solaris 10&nbsp;kernel is somehow throttling the processes so that any
single virtual processor can do no more than 4.16% load.&nbsp; We got this
server last week and I was able to install it in our rack just
yesterday.&nbsp;&nbsp; Now I need to see how I can optimize the postgresql server
to work on this box.&nbsp; Does anyone have any suggestions?&nbsp;&nbsp; I know the
postgresql server is not smp aware but I believe parts of it are.&nbsp; In
particular the buffer manager is supposed to scale the performance
almost linearly with the number of cpu's (including virtual ones).&nbsp; I
don't know however, if I need to recompile the postgresql server myself
to get those benefits.&nbsp;&nbsp; I am using the version of postgresql 8.1.3
that is available on blastwave.org.&nbsp; I am also working with the 64 bit
version of the database server.&nbsp;&nbsp; This machine has over 8GB of ram so I
was thinking of using the&nbsp;64 bit version of the postgresql server so I
can access ram beyong the 4gb limit imposed by 32 bit addressing.&nbsp; Any
help or recommendations for performance tweaking of postgresql is very
much appreciated.</font></span></div>
  <div><span class="812374617-05042006"></span>&nbsp;</div>
  <div><span class="812374617-05042006"></span>&nbsp;</div>
  <div><span class="812374617-05042006"><font face="Arial" size="2">Thanks,</font></span></div>
  <div><span class="812374617-05042006"><font face="Arial" size="2">Juan</font></span></div>
</blockquote>
<br>
</body>
</html>