Postgres 选择 BTREE 而不是 BRIN 索引

我正在运行 Postgres 9.5 并正在使用 BRIN 索引。我有一个大约有 1.5 亿行的事实表，我正在尝试让 PG 使用 BRIN 索引。我的查询是：

select sum(transaction_amt), 
       sum (total_amt) 
from fact_transaction 
where transaction_date_key between 20170101 and 20170201 

我在 transaction_date_key 列（上面的查询指的是 2017 年 1 月到 2017 年 2 月）上创建了 BTREE 索引和 BRIN 索引（默认pages_per_range值为128）。我本以为 PG 会选择使用 BRIN 索引，但它与 BTREE 索引搭配使用。以下是解释计划：

https://explain.depesz.com/s/uPI

然后我删除了 BTREE 索引，对表进行了真空/分析，然后重新运行查询，结果如下did选择 BRIN 索引，但运行时间要长得多：

https://explain.depesz.com/s/5VXi

事实上，使用 BTREE 索引而不是 BRIN 索引时，我的测试速度更快。我以为这应该是相反的？

我更喜欢使用 BRIN 索引，因为它的尺寸较小，但我似乎无法让 PG 使用它。

注意：我加载了从 2017 年 1 月到 2017 年 6 月的数据（通过 transaction_date_key 定义），因为我读到物理表排序在使用 BRIN 索引时会产生影响。

有谁知道为什么 PG 选择使用 B TREE 索引以及为什么 BRAIN 在我的情况下慢得多？

看起来BRIN索引扫描的选择性不是很强——它返回了3000万行，所有这些都必须重新检查，这就是时间花费的地方。

这可能意味着transaction_date_key与表中行的物理位置没有很好的相关性。

A BRIN 指数发挥作用通过“集中”表块的范围（可以使用存储参数配置多少个pages_per_range，其默认值为 128)。存储每个块范围的索引值的最大值和最小值。

所以表中的很多块范围包含transaction_date_key之间20170101 and 20170201，并且必须扫描所有这些块才能计算查询结果。

我认为有两个选择可以改善这种情况：

• 降低pages_per_range存储参数。这将使索引更大，但会减少“误报”块的数量。

• 对表进行聚类transaction_date_key属性。正如您所发现的，这需要（至少暂时）列上有一个 B 树索引。