【发布时间】：2017-10-18 14:42:09
【问题描述】：
我在 postgres 中注意到，当我们创建一个表时，它似乎会自动在 PRIMARY KEY CONSTRAINT 上创建一个 btree 索引。查看 CONSTRAINT 的属性，它似乎没有聚集。我如何集群它，我应该集群它吗？
【问题讨论】：
标签： postgresql
【发布时间】：2017-10-18 14:42:09
【问题描述】：
你必须使用CLUSTER 命令：
CLUSTER stone.unitloaddetail USING pk10;
请记住，这会在此期间重写表并阻止其他人使用。
此外，修改表数据时不会维护集群，因此如果要保持表集群，则必须安排定期运行 CLUSTER。
【讨论】：
-
有没有办法从 pgadmin 做到这一点？
-
可能。如果全部失败，您可以打开一个 SQL 窗口并输入命令。
-
只是一个想法，如果我必须继续重新聚集，使用索引与主键是否更有意义？
-
@DanielL.VanDenBosch：“索引与主键”是什么意思？主键通过唯一索引强制执行。你不能有没有索引的PK
-
你应该使用现有的索引。额外的索引成本性能和磁盘空间。
解决“应该”部分，这取决于查询需要访问具有集群键相邻值的多行的可能性。
对于具有合成主键的表，在外键列上进行聚类可能更有意义。
假设您有一张桌子或产品。您是否更有可能要求具有以下特性的多种产品：
- 连续的product_id？
- 相同的location_id？
- 相同的type_id？
- 同一个manufacturer_id？
如果在其中一种特殊情况下提高系统性能可以解决问题，那么这就是您应该考虑聚类的列。
如果这样做不能解决问题，那就不要这样做。
【讨论】：
-
经常，至少在我上面的例子中。主键几乎总是任意的。但是它们经常在
JOINs 中使用。从我收集到的。将 Laurenz Albe 提供的代码用于 CLUSTER 主键似乎是个好主意。让我知道你的想法 -
@DanielL.VanDenBosch 是的，如果您有这样一种情况，即您为一批发票生成 20 个 invoice_line，那么您希望 invoice_line 上的主键对于单个发票是连续的。但是，发票表的 FK 将保证对于这些行是相同的，并且对该值进行聚类不仅可以提高性能，还可以更好地向系统的未来维护者展示您的意图。如果没有出现这种 PK 值的关联，就不要在上面聚类。