Received: from localhost (maia-2.hub.org [200.46.204.187])
	by postgresql.org (Postfix) with ESMTP id 88A109FB987;
	Wed, 25 Apr 2007 22:21:49 -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 41797-02; Wed, 25 Apr 2007 22:21:40 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from serv1.oss.ntt.co.jp (serv1.oss.ntt.co.jp [222.151.198.98])
	by postgresql.org (Postfix) with ESMTP id B54979FB984;
	Wed, 25 Apr 2007 22:21:45 -0300 (ADT)
Received: from [172.17.1.90] (unknown [172.17.1.90])
	by serv1.oss.ntt.co.jp (Postfix) with ESMTP id D50C6104001;
	Thu, 26 Apr 2007 10:21:43 +0900 (JST)
Message-ID: <462FFE31.6050707@oss.ntt.co.jp>
Date: Thu, 26 Apr 2007 10:19:45 +0900
From: Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Zeugswetter Andreas ADI SD <ZeugswetterA@spardat.at>
CC: Hannu Krosing <hannu@skype.net>, "Joshua D. Drake" <jd@commandprompt.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>,
	josh@agliodbs.com,  pgsql-hackers@postgresql.org,
	pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Full page writes improvement, code update
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>
	<E1539E0ED7043848906A8FF995BDA57901E7BD64@m0143.s-mxs.net>
	<461ECA4E.9010101@oss.ntt.co.jp>
	<E1539E0ED7043848906A8FF995BDA57901E7BEBE@m0143.s-mxs.net>
	<462856EF.1030005@oss.ntt.co.jp>
	<E1539E0ED7043848906A8FF995BDA57901F3FC4B@m0143.s-mxs.net>
	<462BFB11.7000409@oss.ntt.co.jp>
	<E1539E0ED7043848906A8FF995BDA57901F3FF7A@m0143.s-mxs.net>
In-Reply-To: <E1539E0ED7043848906A8FF995BDA57901F3FF7A@m0143.s-mxs.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200704/494
X-Sequence-Number: 2061

Hi,

Zeugswetter Andreas ADI SD wrote:
>> I don't insist the name and the default of the GUC parameter. 
>>  I'm afraid wal_fullpage_optimization = on (default) makes 
>> some confusion because the default behavior becomes a bit 
>> different on WAL itself.
> 
> Seems my wal_fullpage_optimization is not a good name if it caused
> misinterpretation already :-(
> 
>>>> Amount of WAL after 60min. run of DBT-2 benchmark 
>>>> wal_add_optimization_info = off (default) 3.13GB
>>> how about wal_fullpage_optimization = on (default)
> 
> The meaning of wal_fullpage_optimization = on (default)
> would be the same as your wal_add_optimization_info = off (default).
> (Reversed name, reversed meaning of the boolean value)
> 
> It would be there to *turn off* the (default) WAL full_page
> optimization.
> For your pg_compresslog it would need to be set to off. 
> "add_optimization_info" sounded like added info about/for some
> optimization
> which it is not. We turn off an optimization with the flag for the
> benefit
> of an easier pg_compresslog implementation.

For pg_compresslog to remove full page writes, we need 
wal_add_optimization_info=on.

> 
> As already said I would decouple this setting from the part that sets
> the "removeable full page" flag in WAL, and making the recovery able to
> skip dummy records. This I would do unconditionally.
> 
> Andreas
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq
> 


-- 
-------------
Koichi Suzuki