多列 BRIN 列顺序重要吗？

Question

我在需要实时过滤/查询的表中有大量数据（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;

然后我创建了基于多列的索引，因为所有指定的列将始终用于该视图所针对的单个查询。

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 ...

多列 BRIN 索引可用于涉及索引列的任何子集的查询条件。与 GIN 和 B-tree 或 GiST 不同，索引搜索的有效性与查询条件使用的索引列无关。

...但这不描述列排序，只包含在查询中。

我可以进行实验（并且已经取得了令人惊讶的好结果），但这是一个缓慢的过程，因为实现视图和构建索引需要 2 个多小时，所以我希望有某种事实基础来避免我的猜测浪费很多时间。

Answer 1

我认为 BRIN 索引中的列顺序并不重要 - 根据同一文档：https ://www.postgresql.org/docs/10/indexes-multicolumn.html

与 GIN 类似，但与 B 树或 GiST 不同，无论查询条件使用哪个索引列，索引搜索效率都是相同的。

看起来顺序只对 B 树和 GiST 重要。