Re: [HACKERS] Full page writes improvement, code update
Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>
From: Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>
To: Zeugswetter Andreas ADI SD <ZeugswetterA@spardat.at>
Cc: Hannu Krosing <hannu@skype.net>, "Joshua D. Drake" <jd@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, josh@agliodbs.com, pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org
Date: 2007-04-13T00:09:50Z
Lists: pgsql-hackers
Hi, Sorry, inline reply. Zeugswetter Andreas ADI SD wrote: > > Yup, this is a good summary. > > You say you need to remove the optimization that avoids > the logging of a new tuple because the full page image exists. > I think we must already have the info in WAL which tuple inside the full > page image > is new (the one for which we avoided the WAL entry for). > > How about this: > Leave current WAL as it is and only add the not removeable flag to full > pages. > pg_compresslog then replaces the full page image with a record for the > one tuple that is changed. > I tend to think it is not worth the increased complexity only to save > bytes in the uncompressed WAL though. It is essentially what my patch proposes. My patch includes flag to full page writes which "can be" removed. > Another point about pg_decompresslog: > > Why do you need a pg_decompresslog ? Imho pg_compresslog should already > do the replacing of the > full_page with the dummy entry. Then pg_decompresslog could be a simple > gunzip, or whatever compression was used, > but no logic. Just removing full page writes does not work. If we shift the rest of the WAL, then LSN becomes inconsistent in compressed archive logs which pg_compresslog produces. For recovery, we have to restore LSN as the original WAL. Pg_decompresslog restores removed full page writes as a dumm records so that recovery redo functions won't be confused. Regards; > > Andreas > -- ------------- Koichi Suzuki