Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id D2D616330E5 for ; Tue, 10 Aug 2010 13:27:31 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 08068-08 for ; Tue, 10 Aug 2010 16:27:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.postgresql.org (Postfix) with ESMTP id 79EEF6330C2 for ; Tue, 10 Aug 2010 13:27:24 -0300 (ADT) Received: from [192.168.1.151] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LiIi3-1PE1YP1eCp-00n2m8; Tue, 10 Aug 2010 18:27:23 +0200 Message-ID: <4C617DE8.4030203@2ndquadrant.com> Date: Tue, 10 Aug 2010 12:27:20 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Jeff Davis CC: Scott Carey , Michael March , "pgsql-performance@postgresql.org" Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD References: <1281393719.3667.8.camel@jdavis-ux.asterdata.local> In-Reply-To: <1281393719.3667.8.camel@jdavis-ux.asterdata.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:u2XHiW0b4HYSat5yYKPfI0GGZhrb9l0T0WD0XK5ggmn PCAfSRvBatxmXAW7Y+cLRlPMPC8WqKWz6COVRcM1eAPN1JWMnr YJwa/bR1j4pFxDZZyXp69KOfusIzfYoNhpSkTNwCH292z9bTY0 fw04CLHgQtFIFgHlQS3oI+2By+itVl+Yb2dEKrJX5PHkCmNXL6 l1v17Orgh8KgUu2a5JuQh6kDmhfVtT6xtJb0F/HdbA= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.001 tagged_above=-10 required=5 tests=BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201008/110 X-Sequence-Number: 39953 Jeff Davis wrote: > Depending on which 256K you lose, you might as well lose your entire > database. > Let's be nice and assume that you only lose one 8K block because of the SSD write cache; that's not so bad, right? Guess what--you could easily be the next lucky person who discovers the block corrupted is actually in the middle of the pg_class system catalog, where the list of tables in the database is at! Enjoy getting your data back again with that piece missing. It's really a fun time, I'll tell you that. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us