使用哈希索引和 b+ 树索引时的 Postgres 查询复杂性答案

【问题标题】：Postgres Query Complexity when using hash index and b+ tree index使用哈希索引和 b+ 树索引时的 Postgres 查询复杂性
【发布时间】：2018-10-19 19:31:14
【问题描述】：

我的表 (user_tran) 有 3 个字段“user_id”、“transaction_id”、“time_stamp”

我在time_stamp 上散列索引user_id 和transaction_id（因为我需要进行完全匹配）和b+ 树索引

查询是

select user_id from user_tran where transaction_id = 1 and time_stamp > now() - 3 days; 

select transaction_id from user_tran where user_id = 1 and time_stamp > now() - 3 days;

有谁知道这个查询的复杂性是什么？我知道如果我们只按哈希索引列进行过滤，它将是 o(1) 并且 b+ 树给出 o(lgn)。但是将它们组合在一起呢？

那会是o(lgn + 1)吗？

此外，该表将如何存储在引擎盖下。 DBMS 会同时维护 3 个索引（2 个 hash 和 1 个 b+ 树）吗？

谷歌搜索了一下，没有找到答案。

【问题讨论】：

标签： database postgresql indexing

【解决方案1】：

对于这样的三个索引，使用索引的查询的复杂度将是 O(n)，因为组合多个索引的唯一方法是 位图和 .创建位图需要读取整个索引，即O(n)。

所以，除非单独的条件都不是非常有选择性的，否则我会假设 PostgreSQL 会选择对最具选择性的索引进行常规索引扫描，并使用其他条件作为过滤器。这种查询的复杂性与匹配索引条件的行的百分比成正比（例如，O(1) 如果只有恒定数量的行具有user_id = 1 而与表大小无关)。

这些查询的理想索引是：

CREATE INDEX ON user_tran (transaction_id, time_stamp);
CREATE INDEX ON user_tran (user_id, time_stamp);

【讨论】：