Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 3E9A7632BF6 for ; Mon, 26 Jul 2010 20:01:08 -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 75435-07 for ; Mon, 26 Jul 2010 23:00:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 92CA362DB89 for ; Mon, 26 Jul 2010 20:00:59 -0300 (ADT) Received: from [192.168.1.3] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MLC0j-1OdneC1ImX-0010R6; Tue, 27 Jul 2010 01:00:57 +0200 Message-ID: <4C4E13A7.2080100@2ndquadrant.com> Date: Mon, 26 Jul 2010 19:00:55 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Greg Spiegelberg CC: Yeb Havinga , pgsql-performance@postgresql.org Subject: Re: Testing Sandforce SSD References: <4C4A9452.9070100@gmail.com> <4C4B1F84.5030306@2ndquadrant.com> <4C4C83DF.3010703@gmail.com> <4C4C8CCC.7080406@gmail.com> <4C4D6396.5020707@gmail.com> <4C4DAAE8.3060501@2ndquadrant.com> <4C4DE50B.1060102@gmail.com> <4C4DE5C9.8090004@2ndquadrant.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:MMSvmF6jdDnpDBCxsvhhxxuq3QPTSGsRkhMVvbNzLj5 zPcBKytbWmIt1Y/n4OQkStV3g3JCPqT/YY5LZos7OjhgLxXZ6w yivpvgshvocL5/pQjC1icVliR6WW/FMjkcBW2nYO/lGJPnwyb+ HAKEaeK5vhp0xe7gsGwUCLfSooXP5XQskfnVGNXGNYzdmkKoO1 f3NGJJRCuNkuzUp0pETk2wHyQMLGgfSl5au8MrHI10= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201007/394 X-Sequence-Number: 39783 Greg Spiegelberg wrote: > I know I'm talking development now but is there a case for a pg_xlog > block device to remove the file system overhead and guaranteeing your > data is written sequentially every time? It's possible to set the PostgreSQL wal_sync_method parameter in the database to open_datasync or open_sync, and if you have an operating system that supports direct writes it will use those and bypass things like the OS write cache. That's close to what you're suggesting, supposedly portable, and it does show some significant benefit when it's properly supported. Problem has been, the synchronous writing code on Linux in particular hasn't ever worked right against ext3, and the PostgreSQL code doesn't make the right call at all on Solaris. So there's two popular platforms that it just plain doesn't work on, even though it should. We've gotten reports that there are bleeding edge Linux kernel and library versions available now that finally fix that issue, and that PostgreSQL automatically takes advantage of them when it's compiled on one of them. But I'm not aware of any distribution that makes this easy to try out that's available yet, paint is still wet on the code I think. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us