Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 311156332A9 for ; Tue, 10 Aug 2010 15:29:06 -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 71716-02 for ; Tue, 10 Aug 2010 18:28:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.postgresql.org (Postfix) with ESMTP id E185E632BC8 for ; Tue, 10 Aug 2010 15:28:58 -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=mreu2) with ESMTP (Nemesis) id 0MCuUJ-1OaP7T2HnH-0096Gh; Tue, 10 Aug 2010 20:28:33 +0200 Message-ID: <4C619A4F.7080306@2ndquadrant.com> Date: Tue, 10 Aug 2010 14:28:31 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Brad Nicholson CC: Scott Carey , Michael March , "pgsql-performance@postgresql.org" Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD References: <4C617C80.9080509@2ndquadrant.com> <4C619300.3080400@ca.afilias.info> In-Reply-To: <4C619300.3080400@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:WvyiTH3u4f6HS8vhzUCW85JnxHvDaEMsB12ct5C3ijO UComYHUy2VsMDegxkFEmV29bFOlyIt1M3rEwIplMpLqzQNa4u4 IjiHI8g3ArD/i99/GfMi4SGCqyauEi/BthrbiFB2Uxd9RV8RPK Uq2G5Klrkra1JtCHVRRLBXTsOyyNc30mdsUp/KFPd0zlpsLSQO 9IeDrkwOkvsqFEO1ZWjFRhKLT85TenArgatuuVp34k= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.8 tagged_above=-10 required=5 tests=BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201008/117 X-Sequence-Number: 39960 Brad Nicholson wrote: > What about putting indexes on them? If the drive fails and drops > writes on those, they could be rebuilt - assuming your system can > function without the index(es) temporarily. Dumping indexes on SSD is one of the better uses for them, presuming you can survive what is likely to be an outage from a "can the site handle full load?" perspective while they rebuild after a crash. As I'm sure Brad is painfully aware of already, index rebuilding in PostgreSQL can take a while. To spin my broken record here again, the main thing to note when you consider that--relocate indexes onto SSD--is that the ones you are most concerned about the performance of were likely to be already sitting in RAM anyway, meaning the SSD speedup doesn't help reads much. So the giant performance boost just isn't there in that case. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us