User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 31 Jan 2006 15:19:38 -0800
Subject: Re: Huge Data sets, simple queries
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Jim C. Nasby" <jnasby@pervasive.com>
cc: "Mike Biamonte" <mike@dbeat.com>,
	pgsql-performance@postgresql.org
Message-ID: <C005308A.1B642%llonergan@greenplum.com>
Thread-Topic: [PERFORM] Huge Data sets, simple queries
Thread-Index: AcYmvM4XDGFWGpKwEdqBvAANk63kWA==
In-Reply-To: <20060131231227.GP95850@pervasive.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim,

On 1/31/06 3:12 PM, "Jim C. Nasby" <jnasby@pervasive.com> wrote:

>> The alternating technique in mirroring might improve rotational latency for
>> random seeking - a trick that Tandem exploited, but it won't improve
>> bandwidth.
> 
> Or just work in multiples of tracks, which would greatly reduce the
> impact of delays from seeking.

So, having rediscovered the facts underlying the age-old RAID10 versus RAID5
debate we're back to the earlier points.

RAID10 is/was the best option when latency / random seek was the predominant
problem to be solved, RAID5/50 is best where read bandwidth is needed.
Modern developments in fast CPUs for write checksumming have made RAID5/50 a
viable alternative to RAID10 even when there is moderate write / random seek
workloads and fast read is needed.
    
>> 
>> Works great with standard OS write caching.
> 
> Well, the only problem with that is if the machine crashes for any
> reason you risk having the database corrupted (or at best losing some
> committed transactions).

So, do you routinely turn off Linux write caching?  If not, then there's no
difference.

- Luke