Postgresql中的文本相等运算符性能

Question

就字符串比较性能而言，这个查询是如何工作的(假设last_name上有一个标准的B树索引？

select * from employee where last_name = 'Wolfeschlegelsteinhausenbergerdorff';

因此，当它遍历B树时，我假设它不会对last_name字段中的每个字符进行线性搜索。例如，它不会开始检查第一个字母是否以W开头...假设它不做线性比较，它会做什么呢？

我之所以这样问，是因为我正在考虑编写自己的防重复机制，但我希望性能良好。我最初的想法是对通过API传入的每个字符串进行散列处理(将其转换为某种原始数据类型，可能是一个长字符串)，并将散列代码存储在一个集合/缓存中(每个条目在5分钟后过期)。任何冲突都将/可能提示真正的重复检查，其中已经处理的字符串存储在postgresql中。但我在想，简单地查询postgresql会不会更好，而不是维护我自己的基于内存的哈希集，这些哈希集会在5-10分钟后扰乱旧条目。我可能会使用redis来实现可伸缩性，因为多个节点将读取不同的流。我的一组内存缓存哈希码是否会比仅查询带索引的postgres字符串列(全文匹配而不是文本搜索)更快？

Answer 1

当比较字符串是否相等时，将调用函数texteq。

如果您在src/backend/utils/adt/varlena.c中查找该函数，您会发现使用C库函数memcmp进行了比较。我怀疑你能比这更快。

当您在B树索引中查找该值时，它将与存储在从根页到叶页的每个索引页中的值进行比较，这些值最多为5或6页。

坦率地说，我怀疑你能做到比这更快，但我祝你好运。