Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 864EE63540D; Tue, 2 Feb 2010 14:55:23 -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 61191-09-2; Tue, 2 Feb 2010 18:55:01 +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 5B56E636F2A; Tue, 2 Feb 2010 14:34:21 -0400 (AST) Received: from alap2.localnet (p579FAFE6.dip.t-dialin.net [87.159.175.230]) by mail.anarazel.de (Postfix) with ESMTPSA id 8CCDD448005; Tue, 2 Feb 2010 19:34:19 +0100 (CET) From: Andres Freund To: Robert Haas Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Date: Tue, 2 Feb 2010 19:34:07 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.33-rc5-andres-00243-g6ea299e; KDE/4.3.95; x86_64; ; ) Cc: Tom Lane , Greg Stark , pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org, Michael Clemmons , Hannu Krosing , Scott Marlowe References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com> <23321.1265133015@sss.pgh.pa.us> <603c8f071002021014h4b489f44s9014377e1b38dbc7@mail.gmail.com> In-Reply-To: <603c8f071002021014h4b489f44s9014377e1b38dbc7@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002021934.18444.andres@anarazel.de> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.421 tagged_above=-10 required=5 tests=AWL=0.178, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/20 X-Sequence-Number: 37441 On Tuesday 02 February 2010 19:14:40 Robert Haas wrote: > On Tue, Feb 2, 2010 at 12:50 PM, Tom Lane wrote: > > Andres Freund writes: > >> On Tuesday 02 February 2010 18:36:12 Robert Haas wrote: > >>> I took a look at this patch today and I agree with Tom that > >>> pg_fsync_start() is a very confusing name. I don't know what the > >>> right name is, but this doesn't fsync so I don't think it shuld have > >>> fsync in the name. Maybe something like pg_advise_abandon() or > >>> pg_abandon_cache(). The current name is really wishful thinking: > >>> you're hoping that it will make the kernel start the fsync, but it > >>> might not. I think pg_start_data_flush() is similarly optimistic. > >> > >> What about: pg_fsync_prepare(). > > > > prepare_for_fsync()? > > It still seems mis-descriptive to me. Couldn't the same routine be > used simply to abandon undirtied data that we no longer care about > caching? For now it could - but it very well might be converted to sync_file_range or similar, which would have different "sideeffects". As the potential code duplication is rather small I would prefer to describe the prime effect not the sideeffects... Andres