Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 226E6633CE5 for ; Tue, 10 Aug 2010 14:57:32 -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 59219-01 for ; Tue, 10 Aug 2010 17:57:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by mail.postgresql.org (Postfix) with ESMTP id D6407633A34 for ; Tue, 10 Aug 2010 14:57:23 -0300 (ADT) Message-ID: <4C619300.3080400@ca.afilias.info> Date: Tue, 10 Aug 2010 13:57:20 -0400 From: Brad Nicholson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Greg Smith 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> In-Reply-To: <4C617C80.9080509@2ndquadrant.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.311 tagged_above=-10 required=5 tests=BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201008/114 X-Sequence-Number: 39957 On 8/10/2010 12:21 PM, Greg Smith wrote: > Scott Carey wrote: >> Also, the amount of data at risk in a power loss varies between >> drives. For Intel's drives, its a small chunk of data ( < 256K). >> For some other drives, the cache can be over 30MB of outstanding writes. >> For some workloads this is acceptable > > No, it isn't ever acceptable. You can expect the type of data loss > you get when a cache fails to honor write flush calls results in > catastrophic database corruption. It's not "I lost the last few > seconds"; it's "the database is corrupted and won't start" after a > crash. This is why we pound on this topic on this list. A SSD that > fails to honor flush requests is completely worthless for anything > other than toy databases. You can expect significant work to recover > any portion of your data after the first unexpected power loss under > heavy write load in this environment, during which you're down. We do > database corruption recovery at 2ndQuadrant; while I can't talk about > the details of some recent incidents, I am not speaking theoretically > when I warn about this. > 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. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.