"" The locale settings influence the following SQL features:
Sort order in queries using ORDER BY or the standard comparison operators on textual data
The upper, lower, and initcap functions
Pattern matching operators (LIKE, SIMILAR TO, and POSIX-style regular expressions); locales affect both case insensitive matching and the classification of characters by character-class regular expressions
The to_char family of functions
The ability to use indexes with LIKE clauses
The drawback of using locales other than C or POSIX in PostgreSQL is its performance impact. It slows character handling and prevents ordinary indexes from being used by LIKE. For this reason use locales only if you actually need them.
As a workaround to allow PostgreSQL to use indexes with LIKE clauses under a non-C locale, several custom operator classes exist. These allow the creation of an index that performs a strict character-by-character comparison, ignoring locale comparison rules. Refer to Section 11.9 for more information. Another approach is to create indexes using the C collation, as discussed in Section 23.2. ""
the performance impact sometimes is huge.
Sorting Geohash with "C" locale is sometimes 40% faster: " ORDER BY ST_GeoHash(ST_Transform(ST_Envelope(geom),4326),10) COLLATE "C";"
Re: Difference between C and en_US.UTF-8 Collate & CType in Postgres 10.x
Laurenz Albe <[hidden email]> writes:
> Debraj Manna wrote:
>> Will there be any other difference like in terms of index size, etc?
> The size will be the same, just the ordering will be different.
Just to clarify, index sizes might not be *exactly* the same. Different
ordering rules might lead to different upper-page-split choices as the
index grows, resulting in different amounts of unused space in some index
pages. It should average out to about the same thing though.