在 PostgreSQL 中，关于 citext 性能的奇怪问题？答案

【问题标题】：In PostgreSQL, weird issue about citext performance?在 PostgreSQL 中，关于 citext 性能的奇怪问题？
【发布时间】：2015-09-16 23:23:03
【问题描述】：

在PostgreSQL manual 中，它说citext 只是一个通过调用LOWER() 实现TEXT 数据类型的模块：

citext 模块提供了不区分大小写的字符串类型，文案。本质上，它在比较值时在内部调用 lower。否则，它的行为几乎与文本完全相同。

另一方面，在文档的末尾它说：

citext 不如 text 高效，因为运算符的功能和 B-tree 比较函数必须复制数据和将其转换为小写以进行比较。然而，它是轻微的比使用 lower 获得不区分大小写的匹配更有效。

所以我很困惑，如果它使用LOWER()，它怎么能“比使用lower 稍微高效一些”？

【问题讨论】：

【解决方案1】：

它不调用 SQL 函数lower。正如文档所说，它本质上 在内部调用lower。

调用发生在实现citext 比较操作的C 函数中。他们并没有实际调用lower，而是直接转到底层的str_tolower() 例程。您可以在source code 中亲自看到这一点，在这种情况下，大部分内容相对容易理解。

因此，您节省的或多或少是每次比较的两个 SQL 函数调用的开销。与比较本身的成本相比，这并不是微不足道的，但在典型查询中，您可能永远不会注意到它们中的任何一个与其他成本相邻。

【讨论】：

只是为了完成：在 citext 列上创建的索引仅包含小写数据。因此索引会小很多。在查询中，citext 列上的选择器将被转换为小写一次。然后对于所有以下比较，将使用小写索引。因此，与在查询中使用 lower() 相比，性能提升将是巨大的。大部分提升来自有效地使用索引，而 lower() 查询是不可能的。
@Frankenstein：创建一个UNIQUE INDEX name_idx ON table (LOWER(name))，其中name 是text 列怎么样？它比citext 列上的索引快吗？