Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 536856367FA;
	Wed, 20 Jan 2010 00:02:37 -0400 (AST)
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 05049-04; Wed, 20 Jan 2010 04:02:26 +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 2108F63500B;
	Wed, 20 Jan 2010 00:02:20 -0400 (AST)
Received: from alap2.localnet (e178208094.adsl.alicedsl.de [85.178.208.94])
	by mail.anarazel.de (Postfix) with ESMTPSA id 1530D448007;
	Wed, 20 Jan 2010 05:02:19 +0100 (CET)
From: Andres Freund <andres@anarazel.de>
To: Greg Stark <gsstark@mit.edu>
Subject: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic
	slow createdb)
Date: Wed, 20 Jan 2010 05:02:17 +0100
User-Agent: KMail/1.13.0 (Linux/2.6.33-rc3-andres-00151-gfd6fedc; KDE/4.3.90;
	x86_64; ; )
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>
References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com>
	<407d949e1001180835m79ffe3e4w53e20ce2e1a58f2d@mail.gmail.com>
	<407d949e1001190652i43f4f276x6a485f375647219a@mail.gmail.com>
In-Reply-To: <407d949e1001190652i43f4f276x6a485f375647219a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201001200502.18134.andres@anarazel.de>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.411 tagged_above=-10 required=5 tests=AWL=0.188,
	BAYES_00=-2.599
X-Spam-Level: 
X-Archive-Number: 201001/416
X-Sequence-Number: 37296

Hi Greg,

On Tuesday 19 January 2010 15:52:25 Greg Stark wrote:
> On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark <gsstark@mit.edu> wrote:
> > Looking at this patch for the commitfest I have a few questions.
> 
> So I've touched this patch up a bit:
> 
> 1) moved the posix_fadvise call to a new fd.c function
> pg_fsync_start(fd,offset,nbytes) which initiates an fsync without
> waiting on it. Currently it's only implemented with
> posix_fadvise(DONT_NEED) but I want to look into using sync_file_range
> in the future -- it looks like this call might be good enough for our
> checkpoints.
Why exactly should that depend on fsync? Sure, thats where most of the pain 
comes from now but avoiding that cache poisoning wouldnt hurt otherwise as 
well.

I would rather have it called pg_flush_cache_range or such...

> 2) advised each 64k chunk as we write it which should avoid poisoning
> the cache if you do a large create database on an active system.
> 
> 3) added the promised but afaict missing fsync of the directory -- i
> think we should actually backpatch this.
I think as well. You need it during recursing as well though (where I had 
added it) and not only for the final directory.

> Barring any objections shall I commit it like this?
Other than the two things above it looks fine to me.

Thanks,

Andres