| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | "Walker, James Les" <JAWalker(at)cantor(dot)com> |
| Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Tuning Postgres 9.1 on Windows |
| Date: | 2012-05-01 13:43:00 |
| Message-ID: | CAHyXU0yqWT9BTcOpxSEkH7RygLVbiXVv6exbhWLq2hQ9DHDSFQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, May 1, 2012 at 8:14 AM, Walker, James Les <JAWalker(at)cantor(dot)com> wrote:
> SSD is OCZ-VERTEX3 MI. Controller is LSI SAS2 2008 Falcon. I'm working on installing EDB. Then I can give you some I/O numbers.
It looks like the ssd doesn't have a nv cache and the raid card is a
simple sas hba (which likely isn't doing much for the ssd besides
masking TRIM). The OCZ 'pro' versions are the ones with power loss
protection (see:
http://hothardware.com/Reviews/OCZ-Vertex-3-Pro-SandForce-SF2000-Based-SSD-Preview/).
Note the bullet: "Implements SandForce 2582 Controller with power
loss data protection". It doesn't look like the Vertex 3 Pro is out
yet.
If my hunch is correct, the issue here is that the drive is being
asked to sync data physically and SSD really don't perform well when
the controller isn't in control of when and how to sync data. However
full physical sync is the only way to guarantee data is truly safe in
the context of a unexpected power loss (an nv cache is basically a
compromise on this point).
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Clemens Eisserer | 2012-05-01 14:34:10 | Any disadvantages of using =ANY(ARRAY()) instead of IN? |
| Previous Message | Andy Colson | 2012-05-01 13:42:14 | Re: Tuning Postgres 9.1 on Windows |