PostgreSQL中的聚集索引？

Question

我有一张桌子：

CREATE TABLE users (
        id BIGSERIAL PRIMARY KEY,
        first_name varchar(255) NOT NULL,
        last_name varchar(255) NOT NULL,
        cell_id   BIGINT                  
        ...
)

cell_id 是来自 s2 的 uint64，可以表示地球上的任何位置。

->click here for good description of s2

现在我想在 cell_id 上有一个索引，主要是为了使用相等运算符。

CREATE INDEX user_position ON users (cell_id);

但是现在我担心这个索引会被过度更新和查询，最终导致死锁。

所以我有了做这样的事情的想法

CREATE INDEX user_position_even ON users (cell_id) WHERE user id % 2 = 0
CREATE INDEX user_position_odd ON users (cell_id) WHERE user id % 2 = 1

甚至可能会添加更多索引/稀缺性。

现在我有一些问题：

1. 当我进行查询时，Postgres 会使用这两个索引吗？
2. 这是否有助于保持性能？
3. 我的第一个问题是不是错了？
4. 我应该只使用不同的表而不是索引吗？
5. 还有其他更好的方法吗？

Answer 1

1. 当我进行查询时，Postgres 会使用这两个索引吗？

虽然 postgresql 可以在一张表上使用多个索引，但您的 id 可以被 2 整除或不可整除，因此只能使用这些索引中的一个。

1. 这是否有助于保持性能？

不太可能。 postgresql 上的default index type 是 B-Tree，在这里您实际上是在自己做索引将为您做的部分工作。但只是为了确定基准。

1. 我的第一个问题是不是错了？

我会说这称为过早优化。 B-Tree indexes are pretty good 处理它。如果你真的陷入僵局，请回到这里

B-tree、GiST 和 SP-GiST 索引
短期分享/独占页面级别 锁用于读/写访问。锁被立即释放 在获取或插入每个索引行之后。这些索引类型提供 没有死锁条件的最高并发。

4. 我应该只使用不同的表而不是索引吗？

不，Postgresql 可以处理非常大的表。如果这成为一个问题。分区。

5. 还有其他更好的方法吗？

您没有损坏需要修理的东西。回来后回来。