Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id E870D63274B for ; Mon, 16 Aug 2010 17:54:31 -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 45220-01 for ; Mon, 16 Aug 2010 20:54:24 +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 545BD632629 for ; Mon, 16 Aug 2010 17:54: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=mreu2) with ESMTP (Nemesis) id 0MXkkl-1OQWzq0aBz-00WGxO; Mon, 16 Aug 2010 22:54:22 +0200 Message-ID: <4C69A57B.80605@2ndquadrant.com> Date: Mon, 16 Aug 2010 16:54:19 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Andres Freund CC: Scott Carey , Bruce Momjian , Kenneth Cox , "pgsql-performance@postgresql.org" Subject: Re: Advice configuring ServeRAID 8k for performance References: <201008131817.o7DIH1b03550@momjian.us> <4C6591D9.1080206@2ndquadrant.com> <5687A8AD-CA70-4272-A32C-6AE5F491CEA4@richrelevance.com> <4C69796D.9000408@2ndquadrant.com> <20100816200227.GA3911@anarazel.de> <4C699BE2.50606@2ndquadrant.com> <20100816201838.GB3911@anarazel.de> In-Reply-To: <20100816201838.GB3911@anarazel.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:SV54NQSQCC/Z9pMM7DRb5bdGu5ACsCp5T66GiLbM5BA 6T+mWSJZDO9JIVqV3DmWOjWL1ftHj7NI7ylhfVAxbPrFBbCdvR D6xuKHSj6GqU8WS7Ci9ppm6TUTYWWDlXhvjKD3Pvpa1EdFKk7x sAn7kYNbe5XLx9U3zrX7Fj1SG1nPqo8BIy0XfzghHniC4DF4bi AtBVysivKiqlbYpIonKQbcW2YXFO+JIXwlAwqSg0hU= 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: 201008/162 X-Sequence-Number: 40005 Andres Freund wrote: > A new checkpointing logic + a new syncing logic > (prepare_fsync() earlier and then fsync() later) would be a nice > thing. Do you plan to work on that? > The background writer already caches fsync calls into a queue, so the prepare step you're thinking needs to be there is already. The problem is that the actual fsync calls happen in a tight loop. That we're busy fixing. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us