Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 23E1F1337B95 for ; Fri, 29 Oct 2010 12:57:24 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 24650-07 for ; Fri, 29 Oct 2010 15:57:17 +0000 (UTC) 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 mail.postgresql.org (Postfix) with ESMTP id CF63C1337B7B for ; Fri, 29 Oct 2010 12:57:16 -0300 (ADT) 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 o9TFv6YV002778; Fri, 29 Oct 2010 11:57:06 -0400 (EDT) To: Robert Haas cc: James Mansion , Greg Smith , Kevin Grittner , Bruce Momjian , jd@commandprompt.com, Scott Marlowe , Steve Crawford , pgsql-performance@postgresql.org, Ben Chobot Subject: Re: BBU Cache vs. spindles In-reply-to: References: <4CC04EA50200002500036C5E@gw.wicourts.gov> <201010211935.o9LJZTM21744@momjian.us> <4CC0513E0200002500036C68@gw.wicourts.gov> <4CC3E8BF.4090409@mansionfamily.plus.com> <4CC46479.2050206@2ndquadrant.com> <16724.1287952819@sss.pgh.pa.us> <4CC9DE0F.50401@mansionfamily.plus.com> <26348.1288301177@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Fri, 29 Oct 2010 11:43:58 -0400" Date: Fri, 29 Oct 2010 11:57:06 -0400 Message-ID: <2777.1288367826@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/570 X-Sequence-Number: 40988 Robert Haas writes: > On Thu, Oct 28, 2010 at 5:26 PM, Tom Lane wrote: >> It's true that we don't know whether write() causes an immediate or >> delayed disk write, but we generally don't care that much.  What we do >> care about is being able to ensure that a WAL write happens before the >> data write, and with mmap we don't have control over that. > Well, we COULD keep the data in shared buffers, and then copy it into > an mmap()'d region rather than calling write(), but I'm not sure > there's any advantage to it. Managing address space mappings is a > pain in the butt. In principle that ought to be right about the same speed as using write() to copy the data from shared buffers to kernel disk buffers, anyway. regards, tom lane