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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers