Re: [PATCHES] Full page writes improvement, code update
От | Koichi Suzuki |
---|---|
Тема | Re: [PATCHES] Full page writes improvement, code update |
Дата | |
Msg-id | 462FFE31.6050707@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PATCHES] Full page writes improvement, code update ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: