Andres Freund <and...@anarazel.de> writes: > On 2017-09-27 11:50:56 -0400, Tom Lane wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> 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.
>> Yeah, I was wondering about that too. It would likely mean adding a >> compile time dependency on gperf or similar tool, but we could take >> our standard approach of shipping the output in tarballs, so that only >> developers would really need to install that tool. > I'd been wondering about that too, but I'm not sure I buy that it's > worth the effort. The only real argument I see is that there's probably > multiple cases where it'd be potentially beneficial, not just here. The other question that ought to be answered is whether a gperf hash table would be faster. In principle it could be because of guaranteed-no-collisions, but I have no experience with how fast the constructed hash functions might be compared to our regular one. To me, the real takeaway from this thread is that fmgr_isbuiltin() needs optimization at all; I'd have guessed it didn't matter. But now that we know that it does, it's worth looking hard at what we can squeeze out of it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers