Re: Asynchronous commit | Transaction loss at server crash

SSD and battery backed cache kind of do the same thing, in that they
reduce random access times close to 0. However, most SSDs are still
not considered reliable due to their internal caching systems. hard
drives and bbu RAID are proven solutions, SSD is still not really
there just yet in terms of being proven reliable.

On Thu, May 20, 2010 at 1:02 PM, Balkrishna Sharma <b_ki(at)hotmail(dot)com> wrote:
> Good suggestion. Thanks.
> What's your take on SSD ? I read somewhere that moving the WAL to SSD helps
> as well.
>
>> Date: Thu, 20 May 2010 11:36:31 -0600
>> Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at server
>> crash
>> From: scott(dot)marlowe(at)gmail(dot)com
>> To: b_ki(at)hotmail(dot)com
>> CC: pgsql-admin(at)postgresql(dot)org
>>
>> On Thu, May 20, 2010 at 10:54 AM, Balkrishna Sharma <b_ki(at)hotmail(dot)com>
>> wrote:
>> > I need to support several hundreds of concurrent update/inserts from an
>> > online form with pretty low latency (maybe couple of milliseconds at
>> > max).
>> > Think of a save to database at every 'tab-out' in an online form.
>>
>> You can get nearly the same performance by using a RAID controller
>> with battery backed cache without the same danger of losing
>> transactions.
>>
>> --
>> Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-admin
>
> ________________________________
> The New Busy is not the too busy. Combine all your e-mail accounts with
> Hotmail. Get busy.

--
When fascism comes to America, it will be intolerance sold as diversity.