Received: from maia.hub.org (maia-4.hub.org [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id ED60F6321D9 for ; Thu, 20 May 2010 17:10:29 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 06553-05 for ; Thu, 20 May 2010 20:10:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from bay0-omc3-s21.bay0.hotmail.com (bay0-omc3-s21.bay0.hotmail.com [65.54.190.159]) by mail.postgresql.org (Postfix) with ESMTP id 103196321BA for ; Thu, 20 May 2010 17:10:21 -0300 (ADT) Received: from BAY149-W47 ([65.54.190.189]) by bay0-omc3-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 May 2010 13:10:20 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_57eafb11-3f16-44b0-b4a9-45c91c68003a_" X-Originating-IP: [129.44.63.215] From: Balkrishna Sharma To: CC: Subject: Re: Asynchronous commit | Transaction loss at server crash Date: Thu, 20 May 2010 16:10:19 -0400 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 20 May 2010 20:10:20.0183 (UTC) FILETIME=[78D9CA70:01CAF858] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.909 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201005/200 X-Sequence-Number: 34673 --_57eafb11-3f16-44b0-b4a9-45c91c68003a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What if we don't rely on the cache of SSD=2C i.e. have write-through settin= g and not write-back. Is the performance gain then not significant to justi= fy SSD ? > Date: Thu=2C 20 May 2010 13:35:54 -0600 > Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at server cra= sh > From: scott.marlowe@gmail.com > To: b_ki@hotmail.com > CC: pgsql-admin@postgresql.org >=20 > SSD and battery backed cache kind of do the same thing=2C in that they > reduce random access times close to 0. However=2C most SSDs are still > not considered reliable due to their internal caching systems. hard > drives and bbu RAID are proven solutions=2C SSD is still not really > there just yet in terms of being proven reliable. >=20 > On Thu=2C May 20=2C 2010 at 1:02 PM=2C Balkrishna Sharma wrote: > > Good suggestion. Thanks. > > What's your take on SSD ? I read somewhere that moving the WAL to SSD h= elps > > as well. > > > >> Date: Thu=2C 20 May 2010 11:36:31 -0600 > >> Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at server > >> crash > >> From: scott.marlowe@gmail.com > >> To: b_ki@hotmail.com > >> CC: pgsql-admin@postgresql.org > >> > >> On Thu=2C May 20=2C 2010 at 10:54 AM=2C Balkrishna Sharma > >> 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@postgresql.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. >=20 >=20 >=20 > --=20 > When fascism comes to America=2C it will be intolerance sold as diversity= . >=20 > --=20 > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin =20 _________________________________________________________________ The New Busy is not the old busy. Search=2C chat and e-mail from your inbox= . http://www.windowslive.com/campaign/thenewbusy?ocid=3DPID28326::T:WLMTAGL:O= N:WL:en-US:WM_HMP:042010_3= --_57eafb11-3f16-44b0-b4a9-45c91c68003a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What if we don't rely on the cache of SSD=2C i.e. have write-through settin= g and not write-back. Is the performance gain then not significant to justi= fy SSD ?

>=3B Date: Thu=2C 20 May 2010 13:35:54 -0600
>=3B Su= bject: Re: [ADMIN] Asynchronous commit | Transaction loss at server crash>=3B From: scott.marlowe@gmail.com
>=3B To: b_ki@hotmail.com
&g= t=3B CC: pgsql-admin@postgresql.org
>=3B
>=3B SSD and battery ba= cked cache kind of do the same thing=2C in that they
>=3B reduce rando= m access times close to 0. However=2C most SSDs are still
>=3B not co= nsidered reliable due to their internal caching systems. hard
>=3B dr= ives and bbu RAID are proven solutions=2C SSD is still not really
>=3B= there just yet in terms of being proven reliable.
>=3B
>=3B On = Thu=2C May 20=2C 2010 at 1:02 PM=2C Balkrishna Sharma <=3Bb_ki@hotmail.co= m>=3B wrote:
>=3B >=3B Good suggestion. Thanks.
>=3B >=3B W= hat's your take on SSD ? I read somewhere that moving the WAL to SSD helps<= br>>=3B >=3B as well.
>=3B >=3B
>=3B >=3B>=3B Date: Thu= =2C 20 May 2010 11:36:31 -0600
>=3B >=3B>=3B Subject: Re: [ADMIN] = Asynchronous commit | Transaction loss at server
>=3B >=3B>=3B cra= sh
>=3B >=3B>=3B From: scott.marlowe@gmail.com
>=3B >=3B>= =3B To: b_ki@hotmail.com
>=3B >=3B>=3B CC: pgsql-admin@postgresql.= org
>=3B >=3B>=3B
>=3B >=3B>=3B On Thu=2C May 20=2C 2010 = at 10:54 AM=2C Balkrishna Sharma <=3Bb_ki@hotmail.com>=3B
>=3B >= =3B>=3B wrote:
>=3B >=3B>=3B >=3B I need to support several hu= ndreds of concurrent update/inserts from an
>=3B >=3B>=3B >=3B o= nline form with pretty low latency (maybe couple of milliseconds at
>= =3B >=3B>=3B >=3B max).
>=3B >=3B>=3B >=3B Think of a save= to database at every 'tab-out' in an online form.
>=3B >=3B>=3B>=3B >=3B>=3B You can get nearly the same performance by using a RA= ID controller
>=3B >=3B>=3B with battery backed cache without the = same danger of losing
>=3B >=3B>=3B transactions.
>=3B >=3B= >=3B
>=3B >=3B>=3B --
>=3B >=3B>=3B Sent via pgsql-admi= n mailing list (pgsql-admin@postgresql.org)
>=3B >=3B>=3B To make = changes to your subscription:
>=3B >=3B>=3B http://www.postgresql.= org/mailpref/pgsql-admin
>=3B >=3B
>=3B >=3B ________________= ________________
>=3B >=3B The New Busy is not the too busy. Combine= all your e-mail accounts with
>=3B >=3B Hotmail. Get busy.
>= =3B
>=3B
>=3B
>=3B --
>=3B When fascism comes to Am= erica=2C it will be intolerance sold as diversity.
>=3B
>=3B -- =
>=3B Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)>=3B To make changes to your subscription:
>=3B http://www.postgre= sql.org/mailpref/pgsql-admin

The New Busy is not= the old busy. Search=2C chat and e-mail from your inbox. Get started. = --_57eafb11-3f16-44b0-b4a9-45c91c68003a_--