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 7564811F666B for ; Wed, 5 Apr 2006 22:18:35 -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 72969-04 for ; Wed, 5 Apr 2006 22:18:31 -0300 (ADT) X-Greylist: delayed 00:06:37.306032 by SQLgrey- Received: from smtp-01.mandic.com.br (smtp-01.mandic.com.br [200.225.81.132]) by postgresql.org (Postfix) with ESMTP id AA8D811F6632 for ; Wed, 5 Apr 2006 22:18:27 -0300 (ADT) Received: (qmail 12294 invoked from network); 6 Apr 2006 01:11:47 -0000 Received: from 200227136145-dial-user-ecp.acessonet.com.br (HELO [200.227.136.145]) (18Xbxs2+15XbzMyvpdrclZZOlJ+gZpdy@[200.227.136.145]) (envelope-sender ) by smtp-01.mandic.com.br (qmail-ldap-1.03) with SMTP for ; 6 Apr 2006 01:11:45 -0000 Message-ID: <44346AC4.1070801@nube.com.br> Date: Wed, 05 Apr 2006 22:11:32 -0300 From: Marcelo Tada User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Juan Casero (FL FLC)" CC: josh@agliodbs.com, pgsql-performance@postgresql.org, Luke Lonergan Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3 References: <7583B3F1891CC0429FA4A44952AA539C66FA7D@wfm-exchprd2.wfm.pvt> In-Reply-To: <7583B3F1891CC0429FA4A44952AA539C66FA7D@wfm-exchprd2.wfm.pvt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200604/84 X-Sequence-Number: 18168 Juan, I think that AMD Opteron is more flex (OS and Hardware Upgrade) and then, the best solution.¹ What are you think about the Sun Fire X64 X4200 Server? Take a look in this analysis and performance benchmark². Regards, MTada ¹ http://www.anandtech.com/systems/showdoc.aspx?i=2727&p=2 ² http://www.anandtech.com/systems/showdoc.aspx?i=2727&p=7 Juan Casero (FL FLC) wrote: >I am evaluating this SunFire T2000 as a replacement for an Intel P3 1Ghz >postgresql server. This intel server runs a retail reporting database >on postgresql 8.1.3. I need to realize significant performance gains on >T2000 server to justify the expense. So I need to tune the postgresql >server as much as I can for it. Right now the operating system (solaris >10) sees each thread as a single cpu and only allows each thread 4.16% >of the available cpu resources for processing queries. Since postgresql >is not multithreaded and since I cannot apparently break past the >operating system imposed limits on a single thread I can't fully realize >the performance benefits of the T2000 server unless and until I start >getting lots of people hitting the database server with requests. This >doesn't happen right now. It may happen later on as I write more >applications for the server but I am looking to see if the performance >benefit we can get from this server is worth the price tag right now. >That is why I am looking for ways to tweak postgres on it. > > >Thanks, >Juan > >-----Original Message----- >From: Josh Berkus [mailto:josh@agliodbs.com] >Sent: Wednesday, April 05, 2006 6:02 PM >To: pgsql-performance@postgresql.org >Cc: Juan Casero (FL FLC); Luke Lonergan >Subject: Re: [PERFORM] Sun Fire T2000 and PostgreSQL 8.1.3 > >Juan, > > > >>When I hit >>this pgsql on this laptop with a large query I can see the load spike >>up really high on both of my virtual processors. Whatever, pgsql is >>doing it looks like both cpu's are being used indepently. >> >> > >Nope, sorry, you're being decieved. Postgres is strictly one process, >one >query. > >You can use Bizgres MPP to achieve multithreading; it's proprietary and >you have to pay for it. It does work well, though. > >More importantly, though, you haven't really explained why you care >about multithreading. > >-- >--Josh > >Josh Berkus >Aglio Database Solutions >San Francisco > >---------------------------(end of broadcast)--------------------------- >TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > >