Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 1D20B632CCF; Mon, 28 Dec 2009 19:32:11 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 25361-05; Mon, 28 Dec 2009 23:32:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.anarazel.de (mail.anarazel.de [217.115.131.40]) by mail.postgresql.org (Postfix) with ESMTP id 8C35463333F; Mon, 28 Dec 2009 19:32:00 -0400 (AST) Received: from alap2.localnet (unknown [81.163.101.249]) by mail.anarazel.de (Postfix) with ESMTPSA id AA009448003; Tue, 29 Dec 2009 00:31:57 +0100 (CET) From: Andres Freund To: Tom Lane Subject: Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Date: Tue, 29 Dec 2009 00:31:56 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.33-rc2-andres-00001-g6e0f169; KDE/4.3.85; x86_64; ; ) Cc: pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org, Michael Clemmons , Hannu Krosing , Scott Marlowe References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com> <200912282354.51892.andres@anarazel.de> <3454.1262041588@sss.pgh.pa.us> In-Reply-To: <3454.1262041588@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200912290031.57136.andres@anarazel.de> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200912/249 X-Sequence-Number: 36863 On Tuesday 29 December 2009 00:06:28 Tom Lane wrote: > Andres Freund writes: > > This speeds up CREATE DATABASE from ~9 seconds to something around 0.8s > > on my laptop. Still slower than with fsync off (~0.25) but quite a > > worthy improvement. > > I can't help wondering whether that's real or some kind of > platform-specific artifact. I get numbers more like 3.5s (fsync off) > vs 4.5s (fsync on) on a machine where I believe the disks aren't lying > about write-complete. It makes sense that an fsync at the end would be > a little bit faster, because it would give the kernel some additional > freedom in scheduling the required I/O, but it isn't cutting the total > I/O required at all. So I find it really hard to believe a 10x speedup. I only comfortably have access to two smaller machines without BBU from here (being in the Hacker Jeopardy at the ccc congress ;-)) and both show this behaviour. I guess its somewhat filesystem dependent. Andres