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