|
But if we have write-through setting, failure before the cache can write to disk will result in incomplete transaction (i.e. host will know that the transaction was incomplete). Right ? Two things I need for my system is: 1. Unsuccessful transactions with a notification back that it is unsuccessful is ok but telling it is a successful transaction and not being able to write to database is not acceptable (ever). 2. My write time (random access time) should be as minimal as possible. Can a SSD with write-thru cache achieve this ? Thanks for your inputs. > Date: Thu, 20 May 2010 14:12:33 -0600 > Subject: Re: Asynchronous commit | Transaction loss at server crash > From: scott.marlowe@xxxxxxxxx > To: b_ki@xxxxxxxxxxx > CC: pgsql-admin@xxxxxxxxxxxxxx > > The design of SSD is such that it cannot run without caching. It has > to cache to arrange things to be written out due to issues with the > fact that it cannot write small blocks one at a time but needs to > write large chunks together at once. > > On Thu, May 20, 2010 at 2:10 PM, Balkrishna Sharma <b_ki@xxxxxxxxxxx> wrote: > > What if we don't rely on the cache of SSD, i.e. have write-through setting > > and not write-back. Is the performance gain then not significant to justify > > SSD ? > > > >> Date: Thu, 20 May 2010 13:35:54 -0600 > >> Subject: Re: Asynchronous commit | Transaction loss at server > >> crash > >> From: scott.marlowe@xxxxxxxxx > >> To: b_ki@xxxxxxxxxxx > >> CC: pgsql-admin@xxxxxxxxxxxxxx > >> > >> 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@xxxxxxxxxxx> > >> 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: Asynchronous commit | Transaction loss at server > >> >> crash > >> >> From: scott.marlowe@xxxxxxxxx > >> >> To: b_ki@xxxxxxxxxxx > >> >> CC: pgsql-admin@xxxxxxxxxxxxxx > >> >> > >> >> On Thu, May 20, 2010 at 10:54 AM, Balkrishna Sharma <b_ki@xxxxxxxxxxx> > >> >> 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@xxxxxxxxxxxxxx) > >> >> 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. > >> > >> -- > >> Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) > >> To make changes to your subscription: > >> http://www.postgresql.org/mailpref/pgsql-admin > > > > ________________________________ > > The New Busy is not the old busy. Search, chat and e-mail from your inbox. > > Get started. > > > > -- > When fascism comes to America, it will be intolerance sold as diversity. > > -- > Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. See how. |
