我正在对一个包含时间数据的非常大的表进行分区，并考虑我应该以何种粒度进行分区。 Postgres partition documentation 声称“大量分区可能会大大增加查询计划时间”，并建议将分区与“多达一百个”分区一起使用。
假设我的表保存了十年的数据，如果我按周分区，我最终会得到超过 500 个分区。在排除这一点之前，我想更好地了解分区数量对查询计划时间的影响。是否有人对此进行了基准测试，或者是否有人了解其内部工作原理？
【问题讨论】：
标签： performance postgresql partitioning
查询规划器必须对查询中使用的每个表分区的约束信息进行线性搜索，以确定实际涉及到哪些 - 那些可能包含请求数据所需的行。随着您加入更多表，规划器考虑的查询计划数量呈指数增长。因此，线性搜索加起来足以引起麻烦的确切位置实际上取决于查询的复杂性。加入的次数越多，您受到的打击就越严重。 “多达 100 个”的数字来自于注意到查询计划时间加起来的时间是不平凡的，即使在这一点附近的更简单的查询中也是如此。特别是在响应时间延迟很重要的 Web 应用程序中，这是一个问题。因此警告。
你能支持500吗？当然。但是，您将搜索 500 个检查约束中的每一个，以查找涉及优化器考虑的表的每个查询计划。如果查询计划时间不是您关心的问题，那么您可能不在乎。但是大多数站点最终不喜欢在具有这么多分区的查询计划上花费的时间比例，这就是为什么每月分区是大多数数据集的标准的原因之一。您可以轻松地存储 10 年的数据，每月分区，然后再开始跨入计划开销开始显着的地方。
【讨论】：
“大量分区可能会显着增加查询计划时间”并建议将分区与“多达一百个”分区一起使用。
因为每个额外的分区通常都与检查约束相关联，这会导致规划器想知道需要查询哪些分区。在最佳情况下，规划器会识别出您只访问一个分区并完全摆脱 append 步骤。
就行而言，正如 DNS 和 Seth 所指出的，您的里程数会因硬件而异。不过，一般来说，查询 1M 行表和 10M 行表之间没有显着差异——尤其是如果您的硬盘驱动器允许快速随机访问并且使用您的索引进行集群（参见cluster 语句）最常打的。
【讨论】：
每个表分区占用文件系统上的一个 inode。 “非常大”是一个相对术语，取决于您选择的文件系统的性能特征。如果您想要明确的性能基准，您可能会从您选择的操作系统和 FS 中查看邮件系统的各种性能基准。一般来说，在您进入数万到数十万个表空间之前，我不会担心它（在 FreeBSD 的 UFS2 上使用 dirhash 会赢）。另请注意，同样的限制适用于 PostgreSQL 中的 DATABASES、TABLES 或任何其他文件系统支持的数据库对象。
【讨论】：
如果您不想信任编写代码的 PostgreSQL 开发人员，那么我建议您自己尝试一下，并使用解释分析运行一些示例查询，并使用不同的分区方案对它们进行计时。在任何情况下，您的特定硬件和软件配置都可能主导任何答案。
我假设查询优化器用于确定要使用的连接和限制的行优化缓存存储在每个分区中，因此它可能需要加载和读取每个分区的部分来规划查询。
【讨论】：