sql - PostgreSQL 中的聚簇索引？

Question

我有一张 table :

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. 这是否有助于保持绩效？

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

1. 我的第一个担心是错误的吗？

我会说这称为过早优化。 B-Tree indexes are pretty good在处理它。如果你真的遇到了死锁，请回到这里

B-tree, GiST and SP-GiST indexes
Short-term share/exclusive page-level locks are used for read/write access. Locks are released immediately after each index row is fetched or inserted. These index types provide the highest concurrency without deadlock conditions.

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

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

1. 还有其他方法可以做得更好吗？

您没有坏掉的东西需要修理。当你做的时候回来。