Horton

Re: [HACKERS] Full page writes improvement, code update

Zeugswetter Andreas DCP SD <zeugswettera@spardat.at>

View thread View on postgr.es
From: "Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>
To: "Koichi Suzuki" <suzuki.koichi@oss.ntt.co.jp>
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>
Date: 2007-04-23T15:37:38Z
Lists: pgsql-hackers 
> 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.

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