Hi, On 2017-10-05 17:08:39 +0300, Heikki Linnakangas wrote: > > I pushed a further cleaned up version of these two patches. If you see > > a way to avoid initializing the "trailing" part of the > > fmgr_builtin_oid_index in a different manner, I'm all ears ;) > > You could put a dummy entry at fmgr_builtins[0].
Right, I'd considered that somewhere upthread. Didn't really seem better. > BTW, there's some alignment padding in FmgrBuiltin, when MAXIMUM_ALIGNOF==8. > You could easily shrink the struct from 32 to 24 bytes by moving funcName to > the end of the struct: > > --- a/src/include/utils/fmgrtab.h > +++ b/src/include/utils/fmgrtab.h > @@ -25,11 +25,11 @@ > typedef struct > { > Oid foid; /* OID of the function > */ > - const char *funcName; /* C name of the function */ > short nargs; /* 0..FUNC_MAX_ARGS, or -1 if > variable count */ > bool strict; /* T if function is "strict" */ > bool retset; /* T if function returns a set > */ > PGFunction func; /* pointer to compiled function > */ > + const char *funcName; /* C name of the function */ > } FmgrBuiltin; > > extern const FmgrBuiltin fmgr_builtins[]; Yea, that's probably worthwhile, although I suspect it's not a huge save overall. Do you just want to commit that? > If we care about cache efficiency here, we could move funcName out of the > fmgr_builtins array, to a separate array of the same size. I believe > funcName is only used when you create an internal-language function with > CREATE FUNCTION, and having it in a separate array shouldn't hurt those > lookups. When'd that be beneficial? fmgr_builtins is pretty much only used for internal-language CREATE FUNCTIONs? In other cases oid bounds + mapping array should filter out the access before fmgr_builtins is accessed. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers