Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
Date
Msg-id 12699.1506539175@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-09-27 14:58:36 -0400, Tom Lane wrote:
>> 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.

Yeah, constructing an index table of that sort on top of the existing
FmgrBuiltin array could be done cheaply enough at startup.  It irks me
slightly that it's not part of the read-only text segment, but I can't
say that there's any really measurable impact.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.