From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <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-04 14:56:58 |
Message-ID: | 20220204145658.qtcmbsdawvn3lg3b@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 04, 2022 at 09:53:09AM -0500, Robert Haas wrote:
> On Fri, Feb 4, 2022 at 9:48 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > I guess the idea was to have a compromise between letting rmgr authors choose
> > arbitrary ids to avoid any conflicts, especially with private implementations,
> > without wasting too much memory. But those approaches would be pretty much
> > incompatible with the current definition:
> >
> > +#define RM_CUSTOM_MIN_ID 128
> > +#define RM_CUSTOM_MAX_ID UINT8_MAX
> >
> > even if you only allocate up to the max id found, nothing guarantees that you
> > won't get a quite high id.
>
> Right, which I guess raises another question: if the maximum is
> UINT8_MAX, which BTW I find perfectly reasonable, why are we not just
> defining this as an array of size 256? There's no point in adding code
> complexity to save a few kB of memory.
Agreed, especially if combined with your suggested approach 3 (array of
pointers).
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2022-02-04 15:30:26 | Re: [PATCH] Add min() and max() aggregate functions for xid8 |
Previous Message | Robert Haas | 2022-02-04 14:53:09 | Re: Extensible Rmgr for Table AMs |