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 |
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 |