我应该用UTF-8还是ASCII保存ASCII-only varchar？

Question

我有一个varchar列只包含ASCII符号。我不需要按这个字段排序，但我需要以完全平等的方式进行搜索。

默认语言环境是en.UTF8。如果我使用collate "C"创建此列，我会获得任何收益吗？

Answer 1

是，它是有区别的。

即使您没有故意排序，也有各种操作需要在内部进行排序（某些聚合函数，DISTINCT，嵌套循环联接等）。

此外，在球场上的任何指数具有价值排序内部 - 和观察排序规则，除非COLLATE "C"适用（无排序规则）。

对于搜索完全相等你会想要一个索引 - 哪种方式工作（为平等），但它总体上更快，没有整理规则。根据您的使用案例的细节，效果可能可以忽略不计或实质性。影响随着你的弦的长度而增长。我跑的基准上相关的情况下，前一段时间：

• Slow query ordering by a column in a joined table

此外，还有更多的模式匹配的语言环境“C”选项。另一种方法是使用特殊的varchar_pattern_ops操作符类创建索引。

相关：

• PostgreSQL LIKE query performance variations
• Operator “~<~” uses varchar_pattern_ops index while normal ORDER BY clause doesn't?
• Pattern matching with LIKE, SIMILAR TO or regular expressions in PostgreSQL

的Postgres 9.5推出的性能提升了一个名为“缩写键”技术，它遇到了与问题一些罗CALES。所以它被停用，除了C区域设置。字符串在非C区域设置排序Quoting The release notes of Postgres 9.5.2:

• 禁用缩写键（罗伯特哈斯）

的PostgreSQL 9.5引入逻辑用于通过使用标准C库函数加快串 数据类型的比较strxfrm()作为 替代strcoll()。现在出现glibc （Linux的C库的实现）的大多数版本具有的strxfrm()，其在某些语言环境中可产生字符串比较 与strcoll()不匹配的结果。直到此问题可以更好地表征，请在所有非C语言环境中禁用优化。（C 语言环境是安全的，因为它既不使用strcoll()也不strxfrm()。）

不幸的是，这个问题不仅影响排序也进入 排序在B树索引，这意味着text是B树索引， varchar或char列现在可能会损坏，如果它们根据 排序受影响的语言环境并且在PostgreSQL 9.5.0 或9.5.1下构建或修改。用户应该可能会受影响的索引REINDEX。

目前无法给出详尽的 已知受影响的语言环境列表。 C区域是已知的安全，并且有在基于英语的语言环境，如en_US麻烦没有 证据，但一些 其他流行的语言环境，如de_DE在大多数的glibc 版本是否受到影响。

该问题还说明了整理规则的来源，一般来说。