Postgres中有多少个表分区?

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

要回复问题请先登录注册