Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id F3EEA6344DF for ; Tue, 2 Feb 2010 14:44:03 -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 58312-01-2 for ; Tue, 2 Feb 2010 18:43:42 +0000 (UTC) Received: from mx3.hub.org (mx3.hub.org [206.223.169.73]) by mail.postgresql.org (Postfix) with ESMTP id 92DF464371D for ; Tue, 2 Feb 2010 13:50:39 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mx3.hub.org (Postfix) with ESMTP id 1FEE337B5F4 for ; Tue, 2 Feb 2010 13:50:39 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o12HoFZQ023322; Tue, 2 Feb 2010 12:50:15 -0500 (EST) To: Andres Freund cc: Robert Haas , Greg Stark , pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org, Michael Clemmons , Hannu Krosing , Scott Marlowe Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) In-reply-to: <201002021843.49983.andres@anarazel.de> References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com> <407d949e1001291056q22915b1cqbce5fbc918a15d69@mail.gmail.com> <603c8f071002020936k5723e30kd4eac594092aba3b@mail.gmail.com> <201002021843.49983.andres@anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 02 Feb 2010 18:43:15 +0100" Date: Tue, 02 Feb 2010 12:50:15 -0500 Message-ID: <23321.1265133015@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.535 tagged_above=-10 required=5 tests=AWL=-0.795, BAYES_20=-0.74 X-Spam-Level: X-Archive-Number: 201002/14 X-Sequence-Number: 37435 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()? regards, tom lane