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