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
-
Replace binary search in fmgr_isbuiltin with a lookup array.
- 212e6f34d55c 11.0 landed
-
Add inline murmurhash32(uint32) function.
- 791961f59b79 11.0 cited