我正在对一个包含时态数据的非常大的表进行分区，并考虑分区的粒度。Postgres分区文档声称“大量分区可能会大大增加查询规划时间”，并建议分区与“最多100个”分区一起使用
假设我的表保存了10年的数据，如果我按周分区，最终会有500多个分区。在排除这种可能性之前，我想更好地了解分区数量对查询计划时间的影响。是否有人对此进行了基准测试，或者是否有人了解其内部工作原理
查询计划器必须对查询中使用的表的每个分区的约束信息进行线性搜索，以找出实际涉及的分区——可能包含请求的数据所需的行的分区。当您加入更多的表时，planner所考虑的查询计划的数量将呈指数增长。因此，线性搜索加起来足够麻烦的确切位置实际上取决于查询的复杂性。连接越多，受此影响越严重。“最多100个”数字来自于注意到查询计划时间的总和相当于一个不小的时间量，即使是在这一点上进行更简单的查询。特别是在web应用程序上，响应时间的延迟很重要，这是一个问题；这就是警告
你能支持500吗？当然但是，对于优化器考虑的涉及该表的每个查询计划，您将搜索500个检查约束中的每一个。如果查询计划时间不是您关心的问题，那么您可能不在乎。但是大多数站点最终都不喜欢使用这么多分区进行查询规划所花费的时间比例，这也是为什么每月分区是大多数数据集的标准的原因之一。您可以轻松地存储10年的数据，按月分区，然后再开始过渡到计划开销开始明显的地方