> 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
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)
In response to
pgsql-hackers by date
|Next:||From: Naz Gassiep||Date: 2007-04-24 09:51:25|
|Subject: tsearch2 in 8.3|
|Previous:||From: Michael Meskes||Date: 2007-04-24 07:44:57|
|Subject: Re: [HACKERS] BUG #3244: problem with PREPARE|
pgsql-patches by date
|Next:||From: Heikki Linnakangas||Date: 2007-04-24 11:51:34|
|Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j
|Previous:||From: Hiroki Kataoka||Date: 2007-04-24 07:22:39|
|Subject: Re: Dead Space Map version 3 (simplified)|