pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Mark Lewis <mark.lewis@mir3.com>
To: Brendan Duddridge <brendan@clickspace.com>
Cc: Jim C.Nasby <jnasby@pervasive.com>
Cc: Eric Lam <elam@lisasoft.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Slow restoration question
Date: Tue, 02 May 2006 11:49:15 -0700
Message-ID: <1146595755.12053.111.camel@archimedes> (raw)
In-Reply-To: <622925BE-A31E-42FD-AF6A-68DDF3B4A1B7@clickspace.com>
References: <444F24E9.2010907@lisasoft.com>
	<20060502171617.GZ97354@pervasive.com>
	<622925BE-A31E-42FD-AF6A-68DDF3B4A1B7@clickspace.com>

They are not equivalent.  As I understand it, RAID 0+1 performs about
the same as RAID 10 when everything is working, but degrades much less
nicely in the presence of a single failed drive, and is more likely to
suffer catastrophic data loss if multiple drives fail.

-- Mark

On Tue, 2006-05-02 at 12:40 -0600, Brendan Duddridge wrote:
> Everyone here always says that RAID 5 isn't good for Postgres. We  
> have an Apple Xserve RAID configured with RAID 5. We chose RAID 5  
> because Apple said their Xserve RAID was "optimized" for RAID 5. Not  
> sure if we made the right decision though. They give an option for  
> formatting as RAID 0+1. Is that the same as RAID 10 that everyone  
> talks about? Or is it the reverse?
> 
> Thanks,
> 
> ____________________________________________________________________
> Brendan Duddridge | CTO | 403-277-5591 x24 |  brendan@clickspace.com
> 
> ClickSpace Interactive Inc.
> Suite L100, 239 - 10th Ave. SE
> Calgary, AB  T2G 0V9
> 
> http://www.clickspace.com
> 
> On May 2, 2006, at 11:16 AM, Jim C. Nasby wrote:
> 
> > On Wed, Apr 26, 2006 at 05:14:41PM +0930, Eric Lam wrote:
> >> all dumpfiles total about 17Gb. It has been running for 50ish hrs  
> >> and up
> >> to about the fourth file (5-6 ish Gb) and this is on a raid 5 server.
> >
> > RAID5 generally doesn't bode too well for performance; that could be
> > part of the issue.
> > -- 
> > Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
> > Pervasive Software      http://pervasive.com    work: 512-231-6117
> > vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
> >
> > ---------------------------(end of  
> > broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> >                http://archives.postgresql.org
> >
> 
> 
> 
> ---------------------------(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



view thread (23+ messages)  latest in thread

Message-ID: <1146595755.12053.111.camel@archimedes>
Permalink:  ../1146595755.12053.111.camel@archimedes/
Also on:    postgresql.org/message-id/1146595755.12053.111.camel@archimedes

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: mark.lewis@mir3.com, brendan@clickspace.com, jnasby@pervasive.com, elam@lisasoft.com
  Subject: Re: Slow restoration question
  In-Reply-To: <1146595755.12053.111.camel@archimedes>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox