Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id E91B79FB4D3; Wed, 25 Apr 2007 09:56:55 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 99312-03; Wed, 25 Apr 2007 09:56:47 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from is.rice.edu (is.rice.edu [128.42.42.24]) by postgresql.org (Postfix) with ESMTP id 80ED99FA59C; Wed, 25 Apr 2007 09:56:52 -0300 (ADT) Received: from scan2.mail.rice.edu (scan2.mail.rice.edu [128.42.59.161]) by is.rice.edu (Postfix) with ESMTP id F3F264187D; Wed, 25 Apr 2007 07:56:50 -0500 (CDT) Received: from is.rice.edu ([128.42.42.24]) by scan2.mail.rice.edu (scan2.mail.rice.edu [128.42.59.161]) (amavisd-new, port 10024) with ESMTP id 11450-07; Wed, 25 Apr 2007 07:56:50 -0500 (CDT) Received: by is.rice.edu (Postfix, from userid 18612) id 20F3D4185B; Wed, 25 Apr 2007 07:56:50 -0500 (CDT) Date: Wed, 25 Apr 2007 07:56:49 -0500 From: Kenneth Marshall To: Zeugswetter Andreas ADI SD Cc: Josh Berkus , pgsql-hackers@postgresql.org, Koichi Suzuki , pgsql-patches@postgresql.org Subject: Re: [HACKERS] Full page writes improvement, code update Message-ID: <20070425125649.GD19464@it.is.rice.edu> References: <460886E8.6040907@oss.ntt.co.jp> <462D5A23.9060706@oss.ntt.co.jp> <200704240831.42873.josh@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-2.2.1 at scan2.mail.rice.edu X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/480 X-Sequence-Number: 2047 On Wed, Apr 25, 2007 at 10:00:16AM +0200, Zeugswetter Andreas ADI SD wrote: > > > > 1) To deal with partial/inconsisitent write to the data file at > crash > > > recovery, we need full page writes at the first modification to > pages > > > after each checkpoint. It consumes much of WAL space. > > > > We need to find a way around this someday. Other DBs don't > > do this; it may be becuase they're less durable, or because > > they fixed the problem. > > They eighter can only detect a failure later (this may be a very long > time depending on access and verify runs) or they also write page > images. Those that write page images usually write "before images" to a > different area that is cleared periodically (e.g. during checkpoint). > > Writing to a different area was considered in pg, but there were more > negative issues than positive. > So imho pg_compresslog is the correct path forward. The current > discussion is only about whether we want a more complex pg_compresslog > and no change to current WAL, or an increased WAL size for a less > complex implementation. > Both would be able to compress the WAL to the same "archive log" size. > > Andreas > I definitely am in the camp of not increasing WAL size at all. If we need a bit more complexity to ensure that, so be it. Any approach that increases WAL volume would need to have an amazing benefit to make it warranted. This certainly does not meet that criteria. Ken