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-27T19:02:16Z
Lists: pgsql-hackers
On 2017-09-27 14:58:36 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Honestly before going there I'd rather just have
> > an oid indexed array, computed at compile time.
> 
> Yeah, I'd been kind of wondering about that approach too.  We could have,
> say, a table of int16s indexed by OIDs from 0 to 9999, containing zero or
> an index into the table of FmgrBuiltin structs.  So 20000 bytes of
> constant data, and O(negligible) lookup time other than possible cache
> misses on this table.  But a dynahash-ish hash table built for 2800+
> entries would probably be about that size ...

Well dynahash is *way* too slow for this. But that's pretty much what
the simplehash approach is already doing, anyway.  Right now I think the
correct approach would be to just add an fmgr_startup() function, called
by postmaster / backend startup if EXEC_BACKEND.

Greetings,

Andres Freund


Commits

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

  2. Add inline murmurhash32(uint32) function.