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. > Rebuilding a constant table during every backend start seems like a > pretty brute-force answer. We could relatively easily move it to be once-per-postmaster start for !EXEC_BACKEND builds. Constantly doing expensive binary searches is also pretty brute force ;) I've been wondering about not actually eagerly filling that hashtable, but using it for pretty much all of fmgr.c - but that seems like a good chunk more work... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers