| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Optimization in convert_string_datum? |
| Date: | 2007-05-02 21:28:39 |
| Message-ID: | 21504.1178141319@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-05-02 21:56:55 | Re: Patch queue triage |
| Previous Message | Heikki Linnakangas | 2007-05-02 21:28:26 | Re: Sequential scans |