Re: Optimization in convert_string_datum?
От | Tom Lane |
---|---|
Тема | Re: Optimization in convert_string_datum? |
Дата | |
Msg-id | 21504.1178141319@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Optimization in convert_string_datum? (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Optimization in convert_string_datum?
|
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > I'm reviewing the strxfrm patch, and while comparing that code to the > code in varstr_cmp (which uses the same UTF8/UTF16 workaround but for > strcoll instead), and I noticed that in varstr_cmp we have an > optimization to use a stack based buffer instead of palloc if the string > is short enough. Is convert_string_datum performance-critical enough to > make it worthwhile to put a similar optimization there? No, I don't believe so. It should only get invoked a few times per query at most, since only the planner uses it. It would be far more useful to figure out a way to make that code actually do something sane with multibyte encodings than to micro-optimize what's there. regards, tom lane
В списке pgsql-hackers по дате отправления: