| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Binary search in fmgr_isbuiltin() is a bottleneck. |
| Date: | 2017-09-27 15:30:28 |
| Message-ID: | CA+TgmoY8JUaX18wNzRng5yt_xthQMESTm8YysaMAEUaAzrLrNg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 27, 2017 at 11:18 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> No, I think what Andres is saying is that we ought to build the hash
> table before we ever reach this function, so that we don't have to
> have a branch here to check whether it's been done. I don't see why
> that's particularly hard -- it can be jammed into the startup sequence
> someplace early, I assume. In EXEC_BACKEND builds it will have to be
> redone in each child, but that's just a matter of sticking a call into
> SubPostmasterMain() as well as PostMasterMain().
I suppose an even better approach would be to build a perfect hash
table at compile time so that nothing needs to be built at run-time at
all, but I'm not sure it's worth the trouble.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-09-27 15:32:37 | Re: Multicolumn hash indexes |
| Previous Message | Robert Haas | 2017-09-27 15:18:14 | Re: Binary search in fmgr_isbuiltin() is a bottleneck. |