Re: Binary search in fmgr_isbuiltin() is a bottleneck.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Date: 2017-09-27 18:47:36
Message-ID: 20170927184736.eean2zgrbybhhq4l@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-09-27 14:40:20 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-09-27 18:47:45 list of credits for release notes
Previous Message Tom Lane 2017-09-27 18:40:20 Re: Binary search in fmgr_isbuiltin() is a bottleneck.