DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=TxgFhuudLKa3tgMem9GbvCLg/4mvo8HJcyhSTGPDFCbbAwBZXWzAcsg267179+JU5S8d9FlMZ11q4DbPwMwr7QmYZYPHtZzXUgPKKUhnaV//8eaGwn7GNXDZRcAWTU5Jxyh3U/+eEh13Tjf7JHK6G586z6eqY+ExFEEicXXF6/A=
Message-ID: <33c6269f0512260932g38c9b7a4uc2aba00f72ff77@mail.gmail.com>
Date: Mon, 26 Dec 2005 12:32:19 -0500
From: Alex Turner <armtuk@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: What's the best hardver for PostgreSQL 8.1?
In-Reply-To: <20051225173755.GA6986@mathom.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43A84D03.7090002@ritek.hu> <docq5v$24ea$1@news.hub.org>
	<200512212209.50234.caseroj@comcast.net>
	<200512212231.55100.caseroj@comcast.net>
	<20051224135042.484c6e32.frank@wiles.org>
	<6.2.5.6.0.20051224161551.01dc5d98@earthlink.net>
	<Pine.LNX.4.62.0512241350010.2807@qnivq.ynat.uz>
	<6.2.5.6.0.20051224172653.01dd4c08@earthlink.net>
	<20051225173755.GA6986@mathom.us>

It's irrelavent what controller, you still have to actualy write the
parity blocks, which slows down your write speed because you have to
write n+n/2 blocks. instead of just n blocks making the system write
50% more data.

RAID 5 must write 50% more data to disk therefore it will always be slower.

Alex.

On 12/25/05, Michael Stone <mstone+postgres@mathom.us> wrote:
> On Sat, Dec 24, 2005 at 05:45:20PM -0500, Ron wrote:
> >Caches help, and the bigger the cache the better, but once you are
> >doing enough writes fast enough (and that doesn't take much even with
> >a few GBs of cache) the recalculate-checksums-and-write-new-ones
> >overhead will decrease the write speed of real data.  Bear in mind
> >that the HD's _raw_ write speed hasn't been decreased.  Those HD's
> >are pounding away as fast as they can for you.  Your _effective_ or
> >_data level_ write speed is what decreases due to overhead.
>
> You're overgeneralizing. Assuming a large cache and a sequential write,
> there's need be no penalty for raid 5. (For random writes you may
> need to read unrelated blocks in order to calculate parity, but for
> large sequential writes the parity blocks should all be read from
> cache.) A modern cpu can calculate parity for raid 5 on the order of
> gigabytes per second, and even crummy embedded processors can do
> hundreds of megabytes per second. You may have run into some lousy
> implementations, but you should be much more specific about what
> hardware you're talking about instead of making sweeping
> generalizations.
>
> >Side Note: people often forget the other big reason to use RAID 10
> >over RAID 5.  RAID 5 is always only 2 HD failures from data
> >loss.  RAID 10 can lose up to 1/2 the HD's in the array w/o data loss
> >unless you get unlucky and lose both members of a RAID 1 set.
>
> IOW, your RAID 10 is only 2 HD failures from data loss also. If that's
> an issue you need to go with RAID 6 or add another disk to each mirror.
>
> Mike Stone
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>