I wrote: > Currently, we include the function name string in each FmgrBuiltin > struct, whose size is 24 bytes on 64 bit platforms. As far as I can > tell, the name is usually unused, so the attached (WIP, untested) > patch stores it separately, reducing this struct to 16 bytes. > > We can go one step further and allocate the names as a single > character string, reducing the binary size. It doesn't help much to > store offsets, since there are ~40k characters, requiring 32-bit > offsets. If we instead compute the offset on the fly from stored name > lengths, we can use 8-bit values, saving 19kB of space in the binary > over using string pointers.
I tested with the attached C function to make sure fmgr_internal_function() still returned the correct answer. I assume this is not a performance critical function, but I still wanted to see if there was a visible performance regression. I get this when calling fmgr_internal_function() 100k times: master: 833ms patch: 886ms The point of the patch is to increase the likelihood of fmgr_isbuiltin() finding the fmgr_builtins[] element in L1 cache. It seems harder to put a number on that for a realistic workload, but reducing the array size by 1/3 couldn't hurt. I'll go ahead and add this to the commitfest. -- John Naylor https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
drive_builtin_by_name.c
Description: Binary data