| From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Luke Koops <luke(dot)koops(at)entrust(dot)com>, Joseph S <jks(at)selectacast(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: What exactly is postgres doing during INSERT/UPDATE ? |
| Date: | 2009-08-31 14:48:09 |
| Message-ID: | 20090831144809.GF12444@oak.highrise.ca |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
* Merlin Moncure <mmoncure(at)gmail(dot)com> [090831 10:38]:
> I agree, that's good analysis. The main point I was making was that
> if you have say a 10 disk raid 5, you don't involve 10 disks, only
> two...a very common misconception. I made another mistake that you
> didn't catch: you need to read *both* the data drive and the parity
> drive before writing, not just the parity drive.
>
> I wonder if flash SSD are a better fit for raid 5 since the reads are
> much cheaper than writes and there is no rotational latency. (also,
> $/gb is different, and so are the failure cases).
The other thing that scares me about raid-5 is the write-hole, and the
possible delayed inconsistency that brings...
Again, hopefully mitigated by a dependable controller w/ BBU...
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2009-08-31 15:24:01 | Re: What exactly is postgres doing during INSERT/UPDATE ? |
| Previous Message | Merlin Moncure | 2009-08-31 14:38:25 | Re: What exactly is postgres doing during INSERT/UPDATE ? |