Thread: Optimization in convert_string_datum?

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?

//Magnus

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

> > 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