Re: Extensible Rmgr for Table AMs

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Extensible Rmgr for Table AMs
Дата
Msg-id 20220204145658.qtcmbsdawvn3lg3b@jrouhaud
обсуждение исходный текст
Ответ на Re: Extensible Rmgr for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Extensible Rmgr for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Список 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@gmail.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).



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Extensible Rmgr for Table AMs
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: [PATCH] Add min() and max() aggregate functions for xid8