Re: Asynchronous commit | Transaction loss at server crash

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

In response to

Browse pgsql-admin by date

  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