可以在 PostgreSQL 中的主键上使用 BRIN 索引
Possible to use a BRIN Index on a Primary Key in PostgreSQL
我正在阅读 PostgreSQL 中的 BRIN 索引，它似乎对我们使用的许多表都有好处。
也就是说，它很好地适用于已经是主键的列，在这种情况下，添加单独的索引会抵消索引的 部分 好处，即space 节省。
PK 是隐式索引的，不是吗？关于这一点，假设 Btree 也是隐式的，是否可以使用 BRIN 而不是 Btree 来完成？
我试过了，果然没用：
create table foo (
id integer,
constraint foo_pk primary key using BRIN (id)
)
那么，两个问题：
- 可以在 PK 上使用 BRIN 索引吗？
- 如果不是，如果我同时拥有 PK 和单独的 BRIN 索引（如果性能对我来说比 space 更重要），规划者会选择两者中更合适的那个吗？
当然也有可能是我的理解不全面，请指教。
- 主键是NOT NULL和UNIQUE的逻辑组合，因此只能使用支持唯一性的索引类型。
来自 PostgreSQL documentation（当前版本 13）：
Only B-tree currently supports unique indexes.
- 我不太确定 BRIN 会比 B 树更快。 It's a lot more space-efficient, but the fact that it's lossy and requires a secondary verification pass erodes any potential speed advantages. 一旦您被锁定在 B 树主键索引中，就没有太多意义来制作次级重叠 BRIN 索引。
我正在阅读 PostgreSQL 中的 BRIN 索引，它似乎对我们使用的许多表都有好处。
也就是说，它很好地适用于已经是主键的列，在这种情况下，添加单独的索引会抵消索引的 部分 好处，即space 节省。
PK 是隐式索引的，不是吗？关于这一点，假设 Btree 也是隐式的，是否可以使用 BRIN 而不是 Btree 来完成？
我试过了，果然没用：
create table foo (
id integer,
constraint foo_pk primary key using BRIN (id)
)
那么，两个问题：
- 可以在 PK 上使用 BRIN 索引吗？
- 如果不是，如果我同时拥有 PK 和单独的 BRIN 索引（如果性能对我来说比 space 更重要），规划者会选择两者中更合适的那个吗？
当然也有可能是我的理解不全面，请指教。
- 主键是NOT NULL和UNIQUE的逻辑组合，因此只能使用支持唯一性的索引类型。
来自 PostgreSQL documentation（当前版本 13）：
Only B-tree currently supports unique indexes.
- 我不太确定 BRIN 会比 B 树更快。 It's a lot more space-efficient, but the fact that it's lossy and requires a secondary verification pass erodes any potential speed advantages. 一旦您被锁定在 B 树主键索引中，就没有太多意义来制作次级重叠 BRIN 索引。