Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-09-27T18:47:36Z
Lists: pgsql-hackers
On 2017-09-27 14:40:20 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2017-09-27 13:46:50 -0400, Tom Lane wrote: > >> The other question that ought to be answered is whether a gperf hash > >> table would be faster. > > > Ugh, hacking together a quick input file for gperf, I'm *far* from > > convinced. The generated code does multiple lookups in significantly > > sized arrays, and assumes string input. The latter seems like a complete > > dealbreaker, and there doesn't seem to be an option to turn it off. > > Ugh. I'd never actually used gperf, and now I know why not ;-) Heh. > However, that's just the first tool that came to mind. Wikipedia's > article on perfect hashes links to our man Jenkins: > > http://burtleburtle.net/bob/hash/perfect.html > > which looks pretty promising. OTOH, that'd pretty much mean we'd have to include this code in our tree - we can't really expect everyone adding a function to download & compile this manually. Honestly before going there I'd rather just have an oid indexed array, computed at compile time. I've the slight feeling of forgoing the good for the perfect here... Greetings, Andres Freund
Commits
-
Replace binary search in fmgr_isbuiltin with a lookup array.
- 212e6f34d55c 11.0 landed
-
Add inline murmurhash32(uint32) function.
- 791961f59b79 11.0 cited