Re: Inlining comparators as a performance optimisation
От | Tom Lane |
---|---|
Тема | Re: Inlining comparators as a performance optimisation |
Дата | |
Msg-id | 16763.1322838679@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Inlining comparators as a performance optimisation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Inlining comparators as a performance
optimisation
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > OK, but I think it's also going to cost you an extra syscache lookup, > no? You're going to have to check for this new support function > first, and then if you don't find it, you'll have to check for the > original one. I don't think there's any higher-level caching around > opfamilies to save our bacon here, is there? [ shrug... ] If you are bothered by that, get off your duff and provide the function for your datatype. But it's certainly going to be in the noise for btree index usage, and I submit that query parsing/setup involves quite a lot of syscache lookups already. I think that as a performance objection, the above is nonsensical. (And I would also comment that your proposal with a handle is going to involve a table search that's at least as expensive as a syscache lookup.) regards, tom lane
В списке pgsql-hackers по дате отправления: