Re: [HACKERS] Setting pd_lower in GIN metapage
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] Setting pd_lower in GIN metapage |
Дата | |
Msg-id | CAA4eK1Lb7HsBHfhiUUf4LeJY2jkW9ukVK--WSCs=KFhBScN3YA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Setting pd_lower in GIN metapage (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Setting pd_lower in GIN metapage
|
Список | pgsql-hackers |
On Sat, Sep 9, 2017 at 9:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> In short, this patch needs a significant rewrite, and more analysis than >>> you've done so far on whether there's actually any benefit to be gained. >>> It might not be worth messing with. > >> I did some measurements of the compressibility of the GIN meta page, >> looking at its FPWs with and without wal_compression and you are >> right: there is no direct compressibility effect when setting pd_lower >> on the meta page. However, it seems to me that there is an argument >> still pleading on favor of this patch for wal_consistency_checking. > > I think that would be true if we did both my point 1 and 2, so that > the wal replay functions could trust pd_lower to be sane in all cases. > But really, if you have to touch all the places that write these > metapages, you might as well mark them REGBUF_STANDARD while at it. > >> The same comment ought to be mentioned for btree. > > Yeah, I was wondering if we ought not clean up btree/hash while at it. > At the very least, their existing comments saying that it's inessential > to set pd_lower could use some more detail about why or why not. > +1. I think we can even use REGBUF_STANDARD in the hash for metapage where currently it is not used. I can give a try to write a patch for hash/btree part if you want. -- 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 по дате отправления: