Received: from maia.hub.org (maia-1.hub.org [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 8D2F3632D32 for ; Mon, 10 May 2010 20:04:09 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 56762-10 for ; Mon, 10 May 2010 23:03:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.postgresql.org (Postfix) with ESMTP id 22D41632D0E for ; Mon, 10 May 2010 20:04:02 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Mb33T-1Nsibz1D0V-00KLsW; Tue, 11 May 2010 01:03:37 +0200 Message-ID: <4BE890C6.5010907@2ndquadrant.com> Date: Mon, 10 May 2010 19:03:34 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Josh Berkus CC: Kevin Grittner , =?UTF-8?B?Q8OpZHJpYyBWaQ==?= =?UTF-8?B?bGxlbWFpbg==?= , Bernd Helmle , Andrew Dunstan , pgsql-hackers@postgresql.org Subject: Re: no universally correct setting for fsync References: <4BE3D3930200002500031382@gw.wicourts.gov> <4BE425F7.30804@dunslane.net> <4BE3E205020000250003138F@gw.wicourts.gov> <4BE82D6602000025000314D6@gw.wicourts.gov> <4BE87892.5060409@agliodbs.com> In-Reply-To: <4BE87892.5060409@agliodbs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+jP02rWqtessJcw+f+Kv5Apdm8iunVyVdIAvb 7g2QA6Ln50j9tcij7HdK15KJ5gV6XJG/x2MtZr/DPw9kvFWW8X bLd+n1wM+Cp5ZUP4DwOAjh/oH5aR8ah X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201005/487 X-Sequence-Number: 162150 Josh Berkus wrote: >> Wow. In a situation where you save seven minutes (4%), it's hardly >> worth turning off. >> > > I've had it be much higher, especially for really large databases. > Cedric's system had a non-volatile write cache in it. In that case, a few percentage points of improvement is normal--the overhead of fsync is very low. In the case where you don't have one of those, and the write cache on the drives are turned off for safety too, I've seen turning fsync off be a 40X speedup--100 inserts/second jumping to 4000TPS. (This was before synchronous_commit). The real question is how much of a speed-up fsync provides compared to the same workload with synchronous_commit disabled. The only case for fsync=off is one where that number is much faster. That's the case on some low-level operations (I seem to recall there is no async commit speedup for CREATE DATABASE for example). But for most of what people want to speed, just killing sync commit while keeping fsync is on is good enough. I suspect there are still some bulk-load workloads where fsync=off helps beyond just going for async commit, but they're tougher to find and the difference isn't huge relative to total load times. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us