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:18:14 |
Message-ID: | CA+TgmoaxS5ziM45Zkiqoy1kaDJys9_Hz4-4Yu1Diz-yVftP5yg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 25, 2017 at 8:42 AM, Jeevan Ladhe
<jeevan(dot)ladhe(at)enterprisedb(dot)com> wrote:
> As Andres has already pointed, may be we want to move above code in a
> separate
> function, and just call that function here in case the hash is not already
> built.
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().
Aside from that issue, this seems like a pretty boring patch. If a
hash table is faster than a binary search, then it is. Using
simplehash makes sense for this application, I think, and I'm not
really sure what else there is to say.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-09-27 15:30:28 | Re: Binary search in fmgr_isbuiltin() is a bottleneck. |
Previous Message | Alvaro Herrera | 2017-09-27 15:06:49 | Re: Enhancements to passwordcheck |