Postgres选择BTREE而不是BRIN索引

Question

我正在运行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上创建了BTREE索引和BRIN索引(默认pages_per_range值为128)(上述查询指的是2017年1月到2月).我原以为PG会选择使用BRIN索引,但它会与BTREE索引一致.这是解释计划:

然后我删除了BTREE索引,对表进行了真空/分析,并重新运行查询,它确实选择了BRIN索引,但运行时间相当长:

事实上,在使用BTREE索引而不是BRIN索引时,我的测试速度都更快.我以为它应该是相反的？

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

注意:我从2017年1月开始到2017年6月(通过transaction_date_key定义)加载了数据,因为我读到物理表排序在使用BRIN索引时有所不同.

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

Answer 1

似乎BRIN索引扫描不是很有选择性 - 它返回3000万行,所有这些都必须重新检查,这是花费时间的地方.

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

甲BRIN索引作品由"混为一谈"表的块的范围(有多少可以与存储的参数进行配置pages_per_range,其默认值为128).存储块的eatch范围的索引值的最大值和最小值.

因此,表中的许多块范围包含transaction_date_key在20170101和之间20170201,并且必须扫描所有这些块以计算查询结果.

我认为有两种方法可以改善这种情况: