Re: [HACKERS] Full page writes improvement

Tom Lane wrote:
> Koichi Suzuki <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp> writes:
>> Tom Lane wrote:
>>> Doesn't this break crash recovery on PITR slaves?
>
>> Compressed archive log contains the same data as full_page_writes off
>> case. So the influence to PITR slaves is the same as full_page_writes off.
>
> Right. So what is the use-case for running your primary database with
> full_page_writes on and the slaves with it off? It doesn't seem like
> a very sensible combination to me.
>
> Also, it seems to me that some significant performance hit would be
> taken by having to grovel through the log files to remove and re-add the
> full-page data. Plus you are actually writing *more* WAL data out of
> the primary, not less, because you have to save both the full-page
> images and the per-tuple data they normally replace. Do you have
> numbers showing that there's actually any meaningful savings overall?

Yes, I have some evaluations to show that we're writing less and using
overall less resources. Please give me a couple of days to translate.

In the case of PITR slave, because archive logs are read in a short
period, amount of archive log may not be an issue. In the case where
online backup and archive logs must be kept for (relatively) long
period, archive log size is a major issue.

K.Suzuki

>
> regards, tom lane
>

--
Koichi Suzuki