Skip site navigation (1) Skip section navigation (2)

Re: Scaling with memory & disk planning

From: Kurt Gunderson <kgunders(at)cbnlottery(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Scaling with memory & disk planning
Date: 2002-05-30 16:59:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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(at)pexicom(dot)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?

Kurt Gunderson
  Senior Programmer
  Applications Development
  Lottery Group
Canadian Bank Note Company, Limited
Email: kgunders(at)cbnlottery(dot)com
613.225.6566 x326

"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.

In response to


pgsql-general by date

Next:From: McCaffity, Ray (Contractor)Date: 2002-05-30 17:01:58
Subject: Re: erros when making examples in /src/test/examples
Previous:From: Bill GribbleDate: 2002-05-30 16:54:07
Subject: Re: erros when making examples in /src/test/examples

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group