我在需要实时过滤/查询的表中有大量数据(500 多万行)。我一直无法使用常规 b 树索引获得令人满意的性能或可预测的查询计划。我认为使用 BRIN 会有很大帮助,但是因为我们的数据不能插入到我需要查询的任何受控物理顺序中,所以我设置了一个 MATERIALIZED VIEW
选择数据(包括连接数据)并按特定顺序对其进行排序。类似的东西...
CREATE MATERIALIZED VIEW my_view AS
SELECT a.one, b.two, b.three, c.four, c.five, c.six
FROM a, b, c WHERE ...joins
ORDER BY b.three, b.two, a.one, c.four;
然后我创建了基于多列的索引,因为 全部 指定的列将 总是 用于此 View 适用的单个查询。
CREATE INDEX my_view_idx ON my_view
USING BRIN (three, two, one, four) WITH (pages_per_range = 64);
我根据选择性对列(在表和 BRIN 中)进行了排序,意思是
b.three
将过滤掉 80% 的记录(即只有 20% 的记录会匹配),b.two
将过滤掉 70% 等。BRIN 列的排序是否与表的物理排序相同? 我找不到任何描述这一点的资源。我能找到的最接近的东西来自:https://www.postgresql.org/docs/10/indexes-multicolumn.html ...
A multicolumn BRIN index can be used with query conditions that involve any subset of the index's columns. Like GIN and unlike B-tree or GiST, index search effectiveness is the same regardless of which index column(s) the query conditions use.
...但这不描述列排序,只包含在查询中。
我可以进行实验(并且已经取得了令人惊讶的好结果),但这是一个缓慢的过程,因为实现 View 和构建索引需要 2 个多小时,所以我希望有某种事实基础来避免我的猜测浪费很多时间。
最佳答案
我认为 BRIN 索引中的列顺序无关紧要 - 根据同一个文档:https://www.postgresql.org/docs/10/indexes-multicolumn.html
Like GIN and unlike B-tree or GiST, index search effectiveness is the same regardless of which index column(s) the query conditions use.
看起来顺序只对 B-tree 和 GiST 很重要。
关于postgresql - 多列 BRIN 列顺序重要吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59724178/