Skip site navigation (1) Skip section navigation (2)

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

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Koichi Suzuki" <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>,"Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>,<pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Full page writes improvement, code update
Date: 2007-04-24 08:08:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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
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 GassiepDate: 2007-04-24 09:51:25
Subject: tsearch2 in 8.3
Previous:From: Michael MeskesDate: 2007-04-24 07:44:57
Subject: Re: [HACKERS] BUG #3244: problem with PREPARE

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2007-04-24 11:51:34
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Hiroki KataokaDate: 2007-04-24 07:22:39
Subject: Re: Dead Space Map version 3 (simplified)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group