Message-ID: <437DDA26.4000603@rentec.com>
Date: Fri, 18 Nov 2005 08:41:58 -0500
From: Alan Stange <stange@rentec.com>
Reply-To: stange@rentec.com
Organization: Renaissance Technologies Corp.
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
CC: Dave Cramer <pg@fastcrypt.com>, Luke Lonergan <llonergan@greenplum.com>,
	Greg Stark <gsstark@mit.edu>, Joshua Marsh <icub3d@gmail.com>,
	pgsql-performance@postgresql.org
Subject: Re: Hardware/OS recommendations for large databases (
References: <BFA2AFBA.13FC4%llonergan@greenplum.com>
	<0F3B99E2-4575-42B8-8AAC-3FE4B231348C@fastcrypt.com>
	<437DD5A1.1090605@archonet.com>
In-Reply-To: <437DD5A1.1090605@archonet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Richard Huxton wrote:
> Dave Cramer wrote:
>>
>> On 18-Nov-05, at 1:07 AM, Luke Lonergan wrote:
>>
>>> Postgres + Any x86 CPU from 2.4GHz up to Opteron 280 is CPU bound  
>>> after
>>> 110MB/s of I/O.  This is true of Postgres 7.4, 8.0 and 8.1.
>>>
>>> A $1,000 system with one CPU and two SATA disks in a software RAID0  
>>> will
>>> perform exactly the same as a $80,000 system with 8 dual core CPUs  
>>> and the
>>> world's best SCSI RAID hardware on a large database for decision  
>>> support
>>> (what the poster asked about).
>>
>>
>> Now there's an interesting line drawn in the sand. I presume you 
>> have  numbers to back this up ?
>>
>> This should draw some interesting posts.

That's interesting, as I occasionally see more than 110MB/s of 
postgresql IO on our system.  I'm using a 32KB block size, which has 
been a huge win in performance for our usage patterns.   300GB database 
with a lot of turnover.  A vacuum analyze now takes about 3 hours, which 
is much shorter than before.  Postgresql 8.1, dual opteron, 8GB memory, 
Linux 2.6.11, FC drives.

-- Alan