This is interesting. I've been working with databases for ages but hadn't really thought much about collation other than times (mostly with MySQL) when collatio

This is interesting. I've been working with databases for ages but hadn't really thought much about collation other than times (mostly with MySQL) when collation didn't work as expected. Had never thought about it in terms of being a perf issue. For those wanting to save a click, here are the benefits listed in the linked article: The builtin provider's C.UTF-8 offers several important advantages over libc: * faster sorting -- benefits from additional optimizations such as abbreviated keys and varstrfastcmp_c * faster case conversion, e.g. LOWER(), at least compared with some libc implementations * available on all platforms with identical semantics, and the semantics are stable, testable, and documentable within a given Postgres major version Being based on memcmp, the builtin C.UTF-8 locale does not offer natural language sort order. But it is an improvement for most use cases that might otherwise use libc's "C.UTF-8" locale, as well as many use cases that use libc's "C" locale. Here are the benefits mentioned in the original proposal; see it for much more detail: https://www.postgresql.org/message-id/E1rmhxt-004ezT-OB%40gemulon.postgresql.org https://www.postgresql.org/message-id/E1rmhxt-004ezT-OB%40ge... * platform-independent ctype semantics based on Unicode, not tied to any dependency's implementation * ability to combine fast memcmp() collation with rich ctype semantics * user-visible semantics can be documented and tested * stability within a PG major version * transparency of changes: tables would be checked in to .h files, so whoever runs the "update-unicode" build target would see if there are unexpected or impactful changes that should be addressed in the release notes * the built-in tables themselves can be tested exhaustively by comparing with ICU so we can detect trivial parsing errors and the like