In-Reply-To: <BFA2AFBA.13FC4%llonergan@greenplum.com>
References: <BFA2AFBA.13FC4%llonergan@greenplum.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0F3B99E2-4575-42B8-8AAC-3FE4B231348C@fastcrypt.com>
Cc: "Greg Stark" <gsstark@mit.edu>, "Joshua Marsh" <icub3d@gmail.com>,
	pgsql-performance@postgresql.org
Content-Transfer-Encoding: 7bit
From: Dave Cramer <pg@fastcrypt.com>
Subject: Re: Hardware/OS recommendations for large databases (
Date: Fri, 18 Nov 2005 08:00:17 -0500
To: Luke Lonergan <llonergan@greenplum.com>


On 18-Nov-05, at 1:07 AM, Luke Lonergan wrote:

> Greg,
>
>
> On 11/17/05 9:17 PM, "Greg Stark" <gsstark@mit.edu> wrote:
>
>> Ok, a more productive point: it's not really the size of the  
>> database that
>> controls whether you're I/O bound or CPU bound. It's the available  
>> I/O
>> bandwidth versus your CPU speed.
>
> 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.

Dave
>
> Regards,
>
> - Luke
>
>
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>