Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL)
От | Bruce Momjian |
---|---|
Тема | Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL) |
Дата | |
Msg-id | 20120829174334.GA8748@momjian.us обсуждение исходный текст |
Ответ на | C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL) (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>) |
Ответы |
Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL)
Re: C locale versus en_US.UTF8. (Was: String comparision in PostgreSQL) |
Список | 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 по дате отправления: