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
