Re: Huge Data sets, simple queries

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

In response to

Responses

Browse pgsql-performance by date

  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