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

From Koichi Suzuki
Subject Re: [HACKERS] Full page writes improvement, code update
Date
Msg-id 461ECA4E.9010101@oss.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] Full page writes improvement, code update  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Responses Re: [HACKERS] Full page writes improvement, code update
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: autovacuum multiworkers, patch 8
Next
From: NikhilS
Date:
Subject: Re: CREATE TABLE LIKE INCLUDING INDEXES support