From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1
	ubuntu karmic slow createdb)
Date: Tue, 29 Dec 2009 00:20:35 +0100
User-Agent: KMail/1.13.0 (Linux/2.6.33-rc2-andres-00001-g6e0f169; KDE/4.3.85;
	x86_64; ; )
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org,
	Michael Clemmons <glassresistor@gmail.com>,
	Hannu Krosing <hannu@2ndquadrant.com>,
	Scott Marlowe <scott.marlowe@gmail.com>
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: <200912290020.35843.andres@anarazel.de>

On Tuesday 29 December 2009 00:06:28 Tom Lane wrote:
> Andres Freund <andres@anarazel.de> 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.
Well, a template database is about 5.5MB big here - that shouldnt take too 
long when written near-sequentially?
As I said the real benefit only occurred after adding posix_fadvise(.., 
FADV_DONTNEED) which is somewhat plausible, because i.e. the directory entries 
don't need to get scheduled for every file and because the kernel can reorder a 
whole directory nearly sequentially. Without the advice it the kernel doesn't 
know in time that it should write that data back and it wont do it for 5 
seconds by default on linux or such...

I looked at the strace output - it looks sensible timewise to me. If youre 
interested I can give you output of that.

Andres