| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nikolay Shaplov <dhyan(at)nataraj(dot)su> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dent John <denty(at)qqdd(dot)eu>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "Iwata, Aya" <iwata(dot)aya(at)jp(dot)fujitsu(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: [PATCH] Do not use StdRdOptions in Access Methods |
| Date: | 2019-11-21 05:22:18 |
| Message-ID: | 20191121052218.GF153437@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2019-11-21 05:32:41 | Re: [HACKERS] Block level parallel vacuum |
| Previous Message | Dilip Kumar | 2019-11-21 05:16:33 | Re: [HACKERS] Block level parallel vacuum |