From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
Cc: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 2 questions re RAID |
Date: | 2011-06-17 19:50:54 |
Message-ID: | BANLkTi=QE_PPB8y6msnUU3EzBXFuyk63aw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jun 17, 2011 at 11:35 AM, Scott Ribe
<scott_ribe(at)elevated-dev(dot)com> wrote:
> It's small enough that there's some other things going on at the same small server with 4 disk bays ;-) My thinking was that write-back cache might mitigate the poor write performance enough to not be noticed. This db doesn't generally get big batch updates anyway, it's mostly a constant stream of small updates coming in and I have a hard time imagining 256MB of cache filling up very often. (I have at least a fuzzy understanding of how WAL segments affect the write load.)
We run our internal dev server on RAID-6 and it works well enough.
Again, like your usage case, it doesn't get beat up too hard, so
RAID-6 works fine. I prefer RAID-6 because it doesn't degrade as bad
as RAID-5 when a single drive fails, and of course it's still fully
redundant with a single drive failure.
From | Date | Subject | |
---|---|---|---|
Next Message | bubba postgres | 2011-06-17 21:25:10 | Are check constraints always evaluated on UPDATE? |
Previous Message | Scott Ribe | 2011-06-17 19:42:43 | Re: 2 questions re RAID |