Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 2DADB9FB57E for ; Fri, 13 Apr 2007 12:48:11 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 76969-02 for ; Fri, 13 Apr 2007 12:47:52 -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 CF24C9FB9CF for ; Fri, 13 Apr 2007 12:47:52 -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 l3DFlg4f019756; Fri, 13 Apr 2007 11:47:42 -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: <1176478259.3635.176.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> Comments: In-reply-to "Simon Riggs" message dated "Fri, 13 Apr 2007 16:30:58 +0100" Date: Fri, 13 Apr 2007 11:47:41 -0400 Message-ID: <19755.1176479261@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/355 X-Sequence-Number: 1922 "Simon Riggs" writes: > On Fri, 2007-04-13 at 10:36 -0400, Tom Lane wrote: >> That's what bothers me about this patch, too. It will be increasing >> the cost of writing WAL (more data -> more CRC computation and more >> I/O, not to mention more contention for the WAL locks) which translates >> directly to a server slowdown. > I don't really understand this concern. The real objection is that a patch that's alleged to make WAL smaller actually does the exact opposite. Now maybe you can buy that back downstream of the archiver --- after yet more added-on processing --- but it still seems that there's a fundamental misdesign here. > Koichi-san has included a parameter setting that would prevent any > change at all in the way WAL is written. It bothers me that we'd need to have such a switch. That's just another way to shoot yourself in the foot, either by not enabling it (in which case applying pg_compresslog as it stands would actively break your WAL), or by enabling it when you weren't actually going to use pg_compresslog (because you misunderstood the documentation to imply that it'd make your WAL smaller by itself). What I want to see is a patch that doesn't bloat WAL at all and therefore doesn't need a switch. I think Andreas is correct to complain that it should be done that way. regards, tom lane