Re: [HACKERS] Full page writes improvement, code update - Mailing list pgsql-patches

From Zeugswetter Andreas ADI SD
Subject Re: [HACKERS] Full page writes improvement, code update
Date
Msg-id E1539E0ED7043848906A8FF995BDA57901F3FFCC@m0143.s-mxs.net
Whole thread Raw
In response to Re: [HACKERS] Full page writes improvement, code update  (Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>)
Responses Re: [HACKERS] Full page writes improvement, code update  (Josh Berkus <josh@agliodbs.com>)
List pgsql-patches
> 3) To maintain crash recovery chance and reduce the amount of
> archive log, removal of  unnecessary full page writes from
> archive logs is a good choice.

Definitely, yes. pg_compresslog could even move the full pages written
during backup out of WAL and put them in a different file that needs to
be applied before replay of the corresponding WAL after a physical
restore. This would further help reduce log shipping volume.

> To do this, we need both logical log and full page writes in WAL.

This is only true in the sense, that it allows a less complex
implementation of pg_compresslog.

Basically a WAL record consists of info about what happened and
currently eighter per tuple new data or a full page image. The info of
"what happened" together with the full page image is sufficient to
reconstruct the "per tuple new data". There might be a few WAL record
types (e.g. in btree split ?) where this is not so, but we could eighter
fix those or not compress those.

This is why I don't like Josh's suggested name of wal_compressable
eighter.
WAL is compressable eighter way, only pg_compresslog would need to be
more complex if you don't turn off the full page optimization. I think a
good name would tell that you are turning off an optimization.
(thus my wal_fullpage_optimization on/off)

Andreas


pgsql-patches by date:

Previous
From: Hiroki Kataoka
Date:
Subject: Re: Dead Space Map version 3 (simplified)
Next
From: Josh Berkus
Date:
Subject: Re: [HACKERS] Full page writes improvement, code update