Re: [PATCH] Do not use StdRdOptions in Access Methods - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Do not use StdRdOptions in Access Methods
Date
Msg-id 20191121052218.GF153437@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Do not use StdRdOptions in Access Methods  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [PATCH] Do not use StdRdOptions in Access Methods  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Wed, Nov 20, 2019 at 04:44:18PM +0900, Michael Paquier wrote:
> We can do something similar for GIN and BRIN on top of the rest, so
> updated the patch with that.  Nikolay, I would be fine to commit this
> patch as-is.  Thanks for your patience on this stuff.

So, I have reviewed the full thread, and this patch presents a couple
of advantages:
1) Making the code more uniform in terms of reloption build and
handling for index AMs by using more build_reloptions() with custom
parsing tables.
2) Saving a couple of bytes for each relcache entries when rd_options
are built for Btree, Hash and SpGist (StdRdOptions gets a small cut).
The results of this shaving are not much but my take is that it is
always good to shave things if this does not cause extra code
readability churns (even if we have more places which waste more).

Andres, Tomas, I can see that upthread you voiced concerns about the
memory part but not the consistency part.  The patch has become much
smaller after the initial refactoring steps and it is easier to
follow.  Any opinions or objections to share regarding the recent
progress done?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Block level parallel vacuum