> > 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.
ok. > 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. I'm not volunteering to do that - at least not now ;) /Magnus ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
