Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id D07EE6330C2 for ; Tue, 10 Aug 2010 13:21:33 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 00351-05 for ; Tue, 10 Aug 2010 16:21:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mail.postgresql.org (Postfix) with ESMTP id 95386632B9A for ; Tue, 10 Aug 2010 13:21: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=mrbap2) with ESMTP (Nemesis) id 0MRijR-1OKHON0nZh-00TcnP; Tue, 10 Aug 2010 18:21:22 +0200 Message-ID: <4C617C80.9080509@2ndquadrant.com> Date: Tue, 10 Aug 2010 12:21:20 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Scott Carey CC: Michael March , "pgsql-performance@postgresql.org" Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:mcELR8R/bN5caeEPKu6m480NC6nnutqlC8Y4S+FmHG6 bhpYtfau5AF1qsKmdGH/jxlIC5a/n6sV4mSfHnwk7dUPO8tQhG diNVUo7xRzkuqZuXdkUoaNVMo6vL1jqKIkaU8cQBugkIUsgi2O EK73Ta2r9UFpPGjkfm1B2jSxziSMn0Ibfo5gptdbhKbT+tvPHA reIcUFQvaI2zliYVnyRLCDHarNxkd0K1jGKo0v4yN8= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.5 tagged_above=-10 required=5 tests=BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201008/108 X-Sequence-Number: 39951 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. Michael, I would suggest you read http://www.postgresql.org/docs/current/static/wal-reliability.html and link to it at the end of your article. You are recommending that people consider a configuration that will result in their data being lost. That can be acceptable, if for example your data is possible to recreate from backups or the like. But people should be extremely clear that trade-off is happening, and your blog post is not doing that yet. Part of the reason for the bang per buck you're seeing here is that cheap SSDs are cheating. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us