| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Binary search in fmgr_isbuiltin() is a bottleneck. |
| Date: | 2017-09-27 19:11:16 |
| Message-ID: | 20170927191116.ujssdts6cenjuznm@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2017-09-27 15:06:15 -0400, Tom Lane wrote:
> Yeah, constructing an index table of that sort on top of the existing
> FmgrBuiltin array could be done cheaply enough at startup. It irks me
> slightly that it's not part of the read-only text segment, but I can't
> say that there's any really measurable impact.
I don't think this case is significant enough to make it worthwhile, but
if we'd find one that is, we certainly could add code that builds the
hash's array once in memory, then serializes that into a .h file, which
then is included into the code. I can't immediately see more of these
coming up, but who knows?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-09-27 19:30:45 | Re: Binary search in fmgr_isbuiltin() is a bottleneck. |
| Previous Message | Tom Lane | 2017-09-27 19:06:15 | Re: Binary search in fmgr_isbuiltin() is a bottleneck. |