Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.