| 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: | Whole Thread | Raw Message | 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 |