Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id F0A839FA434; Wed, 25 Apr 2007 15:26:48 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 57550-01-4; Wed, 25 Apr 2007 15:26:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by postgresql.org (Postfix) with ESMTP id A833B9FA468; Wed, 25 Apr 2007 15:26:44 -0300 (ADT) X-EthosMedia-Virus-Scanned: no infections found Received: from [63.195.55.98] (account josh@agliodbs.com HELO [192.168.2.3]) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 11998784; Wed, 25 Apr 2007 11:30:50 -0700 From: Josh Berkus Organization: PostgreSQL @ Sun To: "Zeugswetter Andreas ADI SD" Subject: Re: [HACKERS] Full page writes improvement, code update Date: Wed, 25 Apr 2007 11:27:13 -0700 User-Agent: KMail/1.8.2 Cc: pgsql-hackers@postgresql.org, "Koichi Suzuki" , pgsql-patches@postgresql.org References: <460886E8.6040907@oss.ntt.co.jp> <200704240831.42873.josh@agliodbs.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704251127.13624.josh@agliodbs.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/484 X-Sequence-Number: 2051 Andreas, > 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. Huh? As conceived, pg_compresslog does nothing to lower log volume for general purposes, just on-disk storage size for archiving. It doesn't help us at all with the tremendous amount of log we put out for an OLTP server, for example. Not that pg_compresslog isn't useful on its own for improving warm standby managability, but it's completely separate from addressing the "we're logging too much" issue. -- Josh Berkus PostgreSQL @ Sun San Francisco