From: | Rosser Schwarz <rosser(dot)schwarz(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Jesper Krogh <jesper(at)krogh(dot)cc>, Balkrishna Sharma <b_ki(at)hotmail(dot)com>, scott(dot)marlowe(at)gmail(dot)com, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Asynchronous commit | Transaction loss at server crash |
Date: | 2010-05-20 22:12:29 |
Message-ID: | AANLkTikjGoeIRhAprZPvxB2bI9z0msMr0XuObxj0CzJU@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, May 20, 2010 at 4:04 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Also, it's questionable whether a SSD is even going to be faster than
> standard disks for the sequential WAL writes anyway, once a non-volatile
> write cache is available. Â Sequential writes to SSD are the area where the
> gap in performance between them and spinning disks is the smallest.
Yeah, at this point, the only place I'd consider using an SSD in
production is as a tablespace for indexes. Their win is huge for
random IO, and indexes can always be rebuilt. Data, not so much.
Transaction logs, even less.
rls
--
:wq
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-05-20 22:19:46 | Re: Asynchronous commit | Transaction loss at server crash |
Previous Message | Greg Smith | 2010-05-20 22:04:22 | Re: Asynchronous commit | Transaction loss at server crash |