Re: reduce size of fmgr_builtins array

From: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: reduce size of fmgr_builtins array
Date: 2020-01-01 23:15:47
Message-ID: CACPNZCvf4BS9CHt+2AdAWro0YXBDnXPK_RD6h6mN40ivBEVgBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
drive_builtin_by_name.c application/octet-stream 926 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-02 00:46:15 Re: backup manifests
Previous Message Fabien COELHO 2020-01-01 21:55:29 Re: pgbench - use pg logging capabilities