可以使用 BRIN 索引代替 Postgres 中的表分区吗？

Question

给定一个带有 GUID 和时间戳（以及一堆其他列）的仅附加表，该表可以增长约 50Mio 条目/年。我想保持较低的索引数量，只对由 id 查询的数据使用普通（B 树）索引。此外，数据将通过时间戳进行查询以进行分析。为此，我想按月或按年对表进行分区。

但是由于我的表只是附加的并且时间戳将非常连续（可能不是 100% 但通常我不会故意发布过去的项目）不应该 BRIN 索引基本上给我与表分区相同的功能手动创建子表而不是触发器的麻烦？（至少文档中是这样描述分区的：https : //www.postgresql.org/docs/current/static/ddl-partitioning.html）

更新

也许是一些额外的背景——我考虑过按年或月对它进行分区，因为这是唯一可预测的事情。在这两种情况下，我都必须对该表执行查询，该查询将不包含任何时间戳信息，因此对于那些查询，我仍将使用 btree 索引，并且在 prtition postgresql 的情况下无法从查询中推断可以使用哪个较小的表（和索引）。

Answer 1

在这种特定场景中，使用 BRIN（块范围索引）和表分区之间的关键区别在于它们对表大小的影响。表分区通过将表划分为更小、更易于管理的段，有效地减小了表的总体大小。这与 BRIN 形成鲜明对比，BRIN 不会改变表大小。当考虑到索引（尤其是 btree 索引）的增长时，表大小减小的重要性变得尤为明显。在索引超出内存容量的情况下，可能会出现性能问题，不仅对于 btree，对于其他类型的索引也是如此。

此外，这两种方法在数据库的管理和操作方面也存在显着差异。大型表会显着减慢 VACUUM 和 ANALYZE 等维护任务的速度。这些任务以及架构修改操作可能不仅运行速度较慢，而且需要对表进行较长的锁定，这可能会阻碍并发操作的性能并影响数据库系统的整体效率。

另一方面，虽然表分区确实通过减小表大小并可能提高性能来缓解其中一些挑战，但即使有分区，BRIN 索引仍然是必要的。这是因为 BRIN 索引提供的过滤粒度比通过基于分区的约束排除实现的粗过滤要细得多。从本质上讲，BRIN 索引通过提供一种有效的方式来导航分区数据来补充表分区，确保以最佳精度和速度执行查询。

因此，虽然 BRIN 和表分区在管理大型数据集方面提供了显着的优势，但它们具有不同的目的，并且通常结合使用来平衡数据库的性能、可管理性和操作效率。