| 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: | Whole Thread | Raw Message | 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 |