| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Extensible Rmgr for Table AMs |
| Date: | 2022-02-01 23:38:32 |
| Message-ID: | a4958c8fedd6905d4e323bc50b0b64509263d752.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2022-02-01 at 20:45 +0800, Julien Rouhaud wrote:
> On Tue, Feb 01, 2022 at 12:39:38PM +0800, Julien Rouhaud wrote:
> >
> > Other than that the patch looks good to me, as you said we just
> > need a decision
> > on whether custom rmgrs are wanted or not.
>
> One last thing, did you do some benchmark with a couple custom rmgr
> to see how
> much the O(n) access is showing up in profiles?
What kind of a test case would be reasonable there? You mean having a
lot of custom rmgrs?
I was expecting that few people would have more than one custom rmgr
loaded anyway, so a sparse array or hashtable seemed wasteful. If
custom rmgrs become popular we probably need to have a larger ID space
anyway, but it seems like overengineering to do so now.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2022-02-01 23:38:49 | Re: CREATEROLE and role ownership hierarchies |
| Previous Message | Tom Lane | 2022-02-01 23:37:02 | Re: Replace uses of deprecated Python module distutils.sysconfig |