Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 62F07632BEC;
	Mon, 28 Dec 2009 22:55:53 -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 50914-07; Tue, 29 Dec 2009 02:55:42 +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 DAB4263292E;
	Mon, 28 Dec 2009 22:55:42 -0400 (AST)
Received: from alap2.localnet (e178200165.adsl.alicedsl.de [85.178.200.165])
	by mail.anarazel.de (Postfix) with ESMTPSA id EEF65448003;
	Tue, 29 Dec 2009 03:55:39 +0100 (CET)
From: Andres Freund <andres@anarazel.de>
To: Michael Clemmons <glassresistor@gmail.com>
Subject: Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1
	ubuntu karmic slow createdb)
Date: Tue, 29 Dec 2009 03:55:37 +0100
User-Agent: KMail/1.13.0 (Linux/2.6.33-rc2-andres-00001-g6e0f169; KDE/4.3.85;
	x86_64; ; )
Cc: pgsql-hackers@postgresql.org, Greg Smith <greg@2ndquadrant.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org,
	Hannu Krosing <hannu@2ndquadrant.com>,
	Scott Marlowe <scott.marlowe@gmail.com>
References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com>
	<200912290305.39932.andres@anarazel.de>
	<4427a97a0912281853g36e7132al67a73927ae4068c0@mail.gmail.com>
In-Reply-To: <4427a97a0912281853g36e7132al67a73927ae4068c0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200912290355.38382.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/259
X-Sequence-Number: 36873

On Tuesday 29 December 2009 03:53:12 Michael Clemmons wrote:
> Andres,
> Great job.  Looking through the emails and thinking about why this works I
> think this patch should significantly speedup 8.4 on most any file
> system(obviously some more than others) unless the system has significantly
> reduced memory or a slow single core. On a Celeron with 256 memory I
>  suspect it'll crash out or just hit the swap  and be a worse bottleneck. 
>  Anyone have something like this to test on?
Why should it crash? The kernel should just block on writing and write out the 
dirty memory before continuing?
Pg is not caching anything here...

Andres