[HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
От | Andres Freund |
---|---|
Тема | [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck. |
Дата | |
Msg-id | 20170914065128.a5sk7z4xde5uy3ei@alap3.anarazel.de обсуждение исходный текст |
Ответы |
Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck. |
Список | pgsql-hackers |
Hi, Surprising myself I discovered that in workloads that do a large number of fmgr_info* lookups, fmgr_isbuiltin() is actually quite the bottleneck. In my development build we have 2765 builtin functions, stored in a 88KB array. Apparently the ~12 steps are quite noticeable. Generally binary searches have quite a poor memory access pattern... In the workload I playing around with right now (producing this wall of performance fixes) the main source of lookups is printtup_prepare_info(), which does a fmgr_info for every column. If you have a large number of columns ... I think we could conceivable deduplicate the output functions for printtup to one FmgrInfo per type? I'd assume that it'd be good for things besides reducing the overhead - alowing the respective function to reuse fn_extra might be quite good. I've not implemented that idea at this point, I'm not 100% what the best way to do so is without also causing slowdowns. Another idea would be to have an array of FmgrBuiltin*, that we index by oid. That'd not be super small though, given that the space for function oids is sparse. Thus what I've instead done is replacing the binary search in fmgr_isbuiltin() with a simplehash.h style hashtable. After that the lookup is still visible in the profile, but far less prominent. I'd like to move the hash creation out of fmgr_isbuiltin (to avoid having to check whether it's already created), but there's currently no convenient place to create the hash from. Now that we don't rely on the sortedness of fmgrtab.c we could remove a few lines from Gen_fmgrtab.pl, but I don't quite see the advantage. If we were interested in a faster by-name lookup we could sort it by name, but that'd be better solved by another hashtable... I was wondering about also replacing the C function hash with a simplehash, but given that I've not seen this in profiles, I've not bothered so far. 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 по дате отправления: