Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id C32BD1337B7F for ; Thu, 28 Oct 2010 17:33:32 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 06784-04 for ; Thu, 28 Oct 2010 20:33:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from relay.ptn-ipout02.plus.net (relay.ptn-ipout02.plus.net [212.159.7.36]) by mail.postgresql.org (Postfix) with ESMTP id 9CAE41337B66 for ; Thu, 28 Oct 2010 17:33:24 -0300 (ADT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANt6yUzUnw4R/2dsb2JhbAChUXG/OIVIBI1bGQ Received: from outmx02.plus.net ([212.159.14.17]) by relay.ptn-ipout02.plus.net with ESMTP; 28 Oct 2010 21:33:23 +0100 Received: from mansionfamily.plus.com ([80.229.150.39] helo=pd600.barnhouse) by outmx02.plus.net with esmtp (Exim) id 1PBZA2-000599-MJ; Thu, 28 Oct 2010 21:33:22 +0100 Received: from [192.168.0.132] (unknown [192.168.0.132]) by pd600.barnhouse (Postfix) with ESMTP id 8A6583A2579; Thu, 28 Oct 2010 21:41:31 +0100 (BST) Message-ID: <4CC9DE0F.50401@mansionfamily.plus.com> Date: Thu, 28 Oct 2010 21:33:19 +0100 From: James Mansion User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tom Lane CC: 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 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> In-Reply-To: <16724.1287952819@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.6 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7 X-Spam-Level: X-Archive-Number: 201010/561 X-Sequence-Number: 40979 Tom Lane wrote: > The other and probably worse problem is that there's no application > control over how soon changes to mmap'd pages get to disk. An msync > will flush them out, but the kernel is free to write dirty pages sooner. > So if they're depending for consistency on writes not happening until > msync, it's broken by design. (This is one of the big reasons we don't > use mmap'd space for Postgres disk buffers.) > Well, I agree that it sucks for the reason you give - but you use write and that's *exactly* the same in terms of when it gets written, as when you update a byte on an mmap'd page. And you're quite happy to use write. The only difference is that its a lot more explicit where the point of 'maybe its written and maybe it isn't' occurs. There need be no real difference in the architecture for one over the other: there does seem to be evidence that write and read can have better forward-read and write-behind behaviour, because read/write does allow you to initiate an IO with a hint to a size that exceeds a hardware page. And yes, after getting into the details while starting to port TC to Windows, I decided to bin it. Especially handy that SQLite3 has WAL now. (And one last dig - TC didn't even have a checksum that would let you tell when it had been broken: but it might all be fixed now of course, I don't have time to check.) James