Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id C16BF9FB69E for ; Fri, 13 Apr 2007 13:50:47 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 63817-04 for ; Fri, 13 Apr 2007 13:50:44 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id B28039FB783 for ; Fri, 13 Apr 2007 13:50:44 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l3DGoYK1020250; Fri, 13 Apr 2007 12:50:34 -0400 (EDT) To: "Simon Riggs" cc: "Zeugswetter Andreas ADI SD" , "Koichi Suzuki" , "Hannu Krosing" , "Joshua D. Drake" , josh@agliodbs.com, pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org Subject: Re: [HACKERS] Full page writes improvement, code update In-reply-to: <1176480368.3635.199.camel@silverbirch.site> References: <460886E8.6040907@oss.ntt.co.jp> <4609CAC3.7060008@oss.ntt.co.jp> <1175072848.4386.323.camel@silverbirch.site> <200703291145.28574.josh@agliodbs.com> <1175200117.4386.616.camel@silverbirch.site> <460C611E.6090800@oss.ntt.co.jp> <27693.1176226131@sss.pgh.pa.us> <461C3557.6040201@oss.ntt.co.jp> <461C3732.20006@commandprompt.com> <1176269612.3962.11.camel@localhost.localdomain> <461D9090.60808@oss.ntt.co.jp> <461ECA4E.9010101@oss.ntt.co.jp> <19002.1176475004@sss.pgh.pa.us> <1176478259.3635.176.camel@silverbirch.site> <19755.1176479261@sss.pgh.pa.us> <1176480368.3635.199.camel@silverbirch.site> Comments: In-reply-to "Simon Riggs" message dated "Fri, 13 Apr 2007 17:06:08 +0100" Date: Fri, 13 Apr 2007 12:50:33 -0400 Message-ID: <20249.1176483033@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/358 X-Sequence-Number: 1925 "Simon Riggs" writes: > Writing lots of additional code simply to remove a parameter that > *might* be mis-interpreted doesn't sound useful to me, especially when > bugs may leak in that way. My take is that this is simple and useful > *and* we have it now; other ways don't yet exist, nor will they in time > for 8.3. The potential for misusing the switch is only one small part of the argument; the larger part is that this has been done in the wrong way and will cost performance unnecessarily. The fact that it's ready now is not something that I think should drive our choices. I believe that it would be possible to make the needed core-server changes in time for 8.3, and then to work on compress/decompress on its own time scale and publish it on pgfoundry; with the hope that it would be merged to contrib or core in 8.4. Frankly the compress/decompress code needs work anyway before it could be merged (eg, I noted a distinct lack of I/O error checking). regards, tom lane