On Tue, Jan 29, 2002 at 01:54:04PM -0500, Tom Lane wrote:
> Frank Joerdens <frank@joerdens.de> writes:
> > What about the performance penalty that you're warned about with
> > locales (in the admin guide)?
>
> You pay it if you don't select C locale at initdb time, true.
>
> > Does multibyte support entail the same penalty?
>
> AFAIR, MULTIBYTE doesn't kill LIKE optimization, but it does incur
> a generalized performance penalty on all string-mashing operators.
> Never tried to measure the size of the penalty; perhaps Tatsuo or
> Hiroshi would know.
>
> > If not, then multibyte encoding, providing a superset of the
> > locale functionality (correct?), would be better than locales, right?
>
> MULTIBYTE is *not* a superset of LOCALE; they are independently
> enablable features. Offhand I don't think they are both interesting
> for the same character sets.
Ok. But a big advantage then of multibyte vs. locales would be that with
locales I get the performace hit for *all* databases that are hosted
under a particular Pg installation (because initdb settings affect all
databases), whereas with multibyte I get to choose, on a per-database
basis (via createdb or set server_encoding), when I want the locale
support, and when performance is more important.
This line of reasoning obviously only makes any sense if,
funcionality-wise, I don't lose anything by using multibyte instead of
locales (which is what I was trying to say by X provides a superset, in
terms of functionality, of Y . . . not that locale support and multibyte
support are related otherwise, e.g. by sharing bits of code).
Regards, Frank