Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck. |
Дата | |
Msg-id | 20170927190216.kcqqhkbwexyj4v2h@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
|
Список | 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 -- 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 по дате отправления: