Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 25A07633360;
	Mon, 18 Jan 2010 12:36:32 -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 13655-07; Mon, 18 Jan 2010 16:36:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pz0-f180.google.com (mail-pz0-f180.google.com
	[209.85.222.180])
	by mail.postgresql.org (Postfix) with ESMTP id 58B13632C24;
	Mon, 18 Jan 2010 12:36:20 -0400 (AST)
Received: by pzk10 with SMTP id 10so2253197pzk.19
	for <multiple recipients>; Mon, 18 Jan 2010 08:36:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:sender:received:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=5omreyFIlH24igP5a1BB6zK7/iPbbW6YM2L9Qc/dAfk=;
	b=W9nCvdkCtlEfklVzPH+QE5UjgkW09CCZpIWAeow44+oyzT8HZbfo5RUdjYTOEMBfEU
	0hLmASTz6i9/DFO4dCi1n1b1XTzy2rZFHH5rcesxGq3L8XxPZ91OSdN9M/99Le1j/vtz
	sEJqvRARsZUOWq0mwqPNz6oZ1rWy9+qTgTTT4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	b=RHODjqkJg4z1jZFDvGLtl3rU2FcRZ2ocpxLiYJWmUEBIMEnjavqD/o/sIlQsiJJXS1
	CetR2Lx4wT6IpA+9iuONTq5KQy0mz8sZCzR0yiQFx09++Kn1xWA9m5lsT0v9zRgjiUj2
	gOxJ9Ooi7Wl5aAixg9oGmjvA9df0ku8gPJtDI=
MIME-Version: 1.0
Received: by 10.141.106.11 with SMTP id i11mr4510251rvm.239.1263832579120;
	Mon, 18 Jan 2010 08:36:19 -0800 (PST)
In-Reply-To: <200912291930.50812.andres@anarazel.de>
References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com>
	<200912282354.51892.andres@anarazel.de>
	<200912282359.43979.andres@anarazel.de>
	<200912291930.50812.andres@anarazel.de>
From: Greg Stark <gsstark@mit.edu>
Date: Mon, 18 Jan 2010 16:35:59 +0000
X-Google-Sender-Auth: 5863df27f95bd428
Message-ID: <407d949e1001180835m79ffe3e4w53e20ce2e1a58f2d@mail.gmail.com>
Subject: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic
	slow createdb)
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org,
	Michael Clemmons <glassresistor@gmail.com>,
	Hannu Krosing <hannu@2ndquadrant.com>,
	Scott Marlowe <scott.marlowe@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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: 201001/387
X-Sequence-Number: 37267

Looking at this patch for the commitfest I have a few questions.

1) You said you added an fsync of the new directory -- where is that I
don't see it anywhere.

2) Why does the second pass to do the fsyncs read through fromdir to
find all the filenames. I find that odd and counterintuitive. It would
be much more natural to just loop through the files in the new
directory. But I suppose it serves as an added paranoia check that the
files are in fact still there and we're not fsyncing any files we
didn't just copy. I think it should still work, we should have an
exclusive lock on the template database so there really ought to be no
differences between the directory trees.

3) It would be tempting to do the posix_fadvise on each chunk as we
copy it. That way we avoid poisoning the filesystem cache even as far
as a 1G file. This might actually be quite significant if we're built
without the 1G file chunk size. I'm a bit concerned that the code will
be a big more complex having to depend on a good off_t definition
though. Do we only use >1GB files on systems where off_t is capable of
handling >2^32 without gymnastics?

-- 
greg