Re: [HACKERS] Setting pd_lower in GIN metapage - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] Setting pd_lower in GIN metapage
Date
Msg-id CAA4eK1L1m8Argb5A5ObThun4ZbkXbmVODq4gVohZdmbMEpOg=w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Setting pd_lower in GIN metapage  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Setting pd_lower in GIN metapage  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Mon, Sep 25, 2017 at 10:13 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Sun, Sep 24, 2017 at 2:25 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Added and updated the comments for both btree and hash index patches.
>
> I don't have real complaints about this patch, this looks fine to me.
>
> +    * Currently, the advantage of setting pd_lower is in limited cases like
> +    * during wal_consistency_checking or while logging for unlogged relation
> +    * as for all other purposes, we initialize the metapage.  Note, it also
> +    * helps in page masking by allowing to mask unused space.
> I would have reworked this comment a bit, say like that:
> Setting pd_lower is useful for two cases which make use of WAL
> compressibility even if the meta page is initialized at replay:
> - Logging of init forks for unlogged relations.
> - wal_consistency_checking logs extra full-page writes, and this
> allows masking of the unused space of the page.
>
> Now I often get complains that I suck at this exercise ;)
>

I understand that and I think there are always multiple ways to write
same information.  It might be better to pass this patch series to
committer if you don't see any mistake because he might anyway change
some comments before committing.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Rethinking autovacuum.c memory handling
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands