Re: Scaling with memory & disk planning

Bear in mind that I am a newbie to the PostgreSQL world but have
experience in other RDBMSs when I ask this question:

If you are looking for the best performance, why go with a RAID5 as
opposed to a RAID1+0 (mirrored stripes) solution?  Understandably RAID5
is a cheaper solution requiring fewer drives for redundancy but, from my
experience, RAID5 chokes horribly under heavy disk writing.  RAID5
always requires at least two write operations for every block written;
one to the data and one to the redundancy algorithm.

Is this wrong?

(I mean no disrespect)

Tom Lane wrote:

> Doug Fields <dfields-pg-general@pexicom.com> writes:
>
>>d) How much extra performance does having the log or indices on a different
>>disk buy you, esp. in the instance where you are inserting millions of
>>records into a table? An indexed table?
>>
>
> Keeping the logs on a separate drive is a big win, I believe, for heavy
> update situations.  (For read-only queries, of course the log doesn't
> matter.)
>
> Keeping indexes on a separate drive is also traditional database advice,
> but I don't have any feeling for how much it matters in Postgres.
>
>
>>a) Run everything on one 7-drive RAID 5 partition (8th drive as hot spare)
>>b) Run logs as a 2-drive mirror and the rest on a 5-drive RAID 5
>>c) Run logs on a 2-drive mirror, indices on a 2-drive mirror, and the rest
>>on a 3-drive RAID5?
>>d) Run logs & indices on a 2-drive mirror and the rest on a 5-drive RAID 5
>>
>
> You could probably get away without mirroring the indices, if you are
> willing to incur a little downtime to rebuild them after an index drive
> failure.  So another possibility is
>
> 2-drive mirror for log, 1 plain old drive for indexes, rest for data.
>
> If your data will fit on 2 drives then you could mirror both, still have
> your 8th drive as hot spare, and feel pretty secure.
>
> Note that while it is reasonably painless to configure PG with WAL logs
> in a special place (after initdb, move the pg_xlog subdirectory and make
> a symlink to its new location), it's not currently easy to separate
> indexes from data.  So the most practical approach in the short term is
> probably your (b).
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>


--
Kurt Gunderson
  Senior Programmer
  Applications Development
  Lottery Group
Canadian Bank Note Company, Limited
Email: kgunders@cbnlottery.com
Phone:
613.225.6566 x326
Fax:
613.225.6651
http://www.cbnco.com/

"Entropy isn't what is used to be"

Obtaining any information from this message for the purpose of sending
unsolicited commercial Email is strictly prohibited.  Receiving this
email does not constitute a request of or consent to send unsolicited
commercial Email.