Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL) - Mailing list pgsql-general

From Bruce Momjian
Subject Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL)
Date
Msg-id 20120829174334.GA8748@momjian.us
Whole thread Raw
In response to C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL)  (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>)
Responses Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL)  (Merlin Moncure <mmoncure@gmail.com>)
Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL)  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
On Wed, Aug 29, 2012 at 10:31:21AM -0700, Aleksey Tsalolikhin wrote:
> On Wed, Aug 29, 2012 at 9:45 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> > citext unfortunately doesn't allow for index optimization of LIKE
> > queries, which IMNSHO defeats the whole purpose.  to the best way
> > remains to use lower() ...
> > this will be index optimized and fast as long as you specified C
> > locale for your database.
>
> What is the difference between C and en_US.UTF8, please?  We see that
> the same query (that invokes a sort) runs 15% faster under the C
> locale.  The output between C and en_US.UTF8 is identical.  We're
> considering moving our database from en_US.UTF8 to C, but we do deal
> with internationalized text.

Well, C has reduced overhead for string comparisons, but obviously
doesn't work well for international characters.  The single-byte
encodings have somewhat less overhead than UTF8.  You can try using C
locales for databases that don't require non-ASCII characters.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


pgsql-general by date:

Previous
From: Ryan Kelly
Date:
Subject: Re: psql & unix env variables
Next
From: Merlin Moncure
Date:
Subject: Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL)