Re: Extensible Rmgr for Table AMs

On Thu, Feb 3, 2022 at 12:34 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> I agree that having dozen of custom rmgrs doesn't seem likely, but I also have
> no idea of how much overhead you get by not doing a direct array access. I
> think it would be informative to benchmark something like simple OLTP write
> workload on a fast storage (or a ramdisk, or with fsync off...), with the used
> rmgr being the 1st and the 2nd custom rmgr. Both scenario still seems
> plausible and shouldn't degenerate on good hardware.

I think it would be hard to measure the overhead of this approach on a
macrobenchmark. That having been said, I find this a surprising
implementation choice. I think that the approaches that are most worth
considering are:

(1) reallocate the array if needed so that we can continue to just do
RmgrTable[rmid]
(2) have one array for builtins and a second array for extensions and
do rmid < RM_CUSTOM_MIN_ID ? BuiltinRmgrTable[rmid] :
ExtensionRmgrTable[rmid]
(3) change RmgrTable to be an array of pointers to structs rather than
an an array of structs. then the structs don't move around and can be
const, but the pointers can be moved into a larger array if required

I'm not really sure which is best. My intuition for what will be
cheapest on modern hardware is pretty shaky. However, I can't see how
it can be the thing the patch is doing now; a linear search seems like
it has to be the slowest option.

--
Robert Haas
EDB: http://www.enterprisedb.com