Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>,
Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>,
PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-09-27T17:46:50Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2017-09-27 11:50:56 -0400, Tom Lane wrote: >> Robert Haas <robertmhaas@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
Commits
-
Replace binary search in fmgr_isbuiltin with a lookup array.
- 212e6f34d55c 11.0 landed
-
Add inline murmurhash32(uint32) function.
- 791961f59b79 11.0 cited