小编Rya*_*yan的帖子

我正在运行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索引一致.这是解释计划:

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

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

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

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

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

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

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

这是我之前关于Postgres 9.5 Postgres选择BTREE而不是BRIN索引的BRIN索引的帖子的后续问题.

有没有一种智能的方法来计算:

 pages_per_range 

应该在创建BRIN索引时设置值？我有一个事实表,每天将增加大约100万行,我想在date_key列(整数)上放置一个BRIN索引.典型值为20170801(2017年8月1日).

从我之前的帖子中我发现将其设置为默认值的一半(我将其设置为64)导致查询时间大幅增加.我可以选择任意值(如64),但想知道是否有人有另一种(更智能)的方法？

谢谢

瑞安