Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck. |
Дата | |
Msg-id | 15039.1506639148@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.
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > I might be worse than you... But anyway, here's a patch doing > so. Looking at profiles, it turned out that having the integer limits as > extern variables in a different TU isn't a great idea. Uh, what? Access to fmgr_nbuiltins shouldn't be part of any critical path anymore after this change. > So I moved what > used to be fmgrtab.c to fmgrtab.h, and included it directly in fmgr.c. I'm kind of -0.5 on that. I believe part of the argument for having things set up as they were was to allow external code to access the fmgr_builtins table (as my speed-test hack earlier today did). While I'm not sure that anything really is using that API, I do not believe we'd gain any performance by removing it, so why do so? We can leave the table and the fmgr_nbuiltins variable completely as-is, and just add an index table, which fmgr.c could be aware is of size exactly "FirstBootstrapObjectId" entries. > Is this roughly what you were thinking of? I think you need the "no entry" values to be -1; 0 is a valid index into the fmgr table. 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 по дате отправления: