From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | "Mike Biamonte" <mike(at)dbeat(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Huge Data sets, simple queries |
Date: | 2006-01-31 23:19:38 |
Message-ID: | C005308A.1B642%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jim,
On 1/31/06 3:12 PM, "Jim C. Nasby" <jnasby(at)pervasive(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Morin | 2006-01-31 23:25:01 | partitioning and locking problems |
Previous Message | Luke Lonergan | 2006-01-31 23:13:10 | Re: Huge Data sets, simple queries |