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-27T17:00:32Z
Lists: pgsql-hackers
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.


> 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


Commits

  1. Replace binary search in fmgr_isbuiltin with a lookup array.

  2. Add inline murmurhash32(uint32) function.