Database 选择从postgresql数据库中的170个分区读取的查询时间

我计划每小时有一个分区来存储1周的数据。每个分区将有2500万条记录（100万组每个分区产生25条记录）。我能够在30毫秒内为一个组运行3到4个分区的SELECT查询

我的问题是： 用数据创建这么多分区需要花费很多时间。所以，我正在寻找专家知识来预测，查询170个分区需要多少时间？并行处理会带来好处吗

---

另一个问题是：预计表中有42亿条记录。到目前为止，我尝试了1.5亿张唱片。进展顺利。一个POSTGRESQL数据库能容纳近420万条记录吗

这类事情很难预测

分区的创建有多大帮助很大程度上取决于查询优化器在规划查询期间排除分区的能力。查看查询的解释输出，看看它是在访问所有分区还是只是一个子集。如果它可以排除许多分区，这将保持查询速度

为了从并行处理中获得最好的结果，您需要使用版本10。并行表扫描不需要分区，只需扫描足够大的表即可。请参阅配置参数

有关并行查询的更多信息，请阅读

---

Postgresql将毫不费力地保存42亿行。每个表的行数不受限制，表大小限制为32 TB，但在进行分区时，您不会遇到数据库大小也没有限制的情况。它的可用性在很大程度上取决于您的硬件、查询和正确配置postgresql。

感谢Eelke的解释。如果用户选择1周的持续时间，我的查询将命中所有分区。如果查询命中所有170个分区，我会更多地考虑性能。虽然一个分区只需要10毫秒，但对于170个分区来说，不管是2秒还是3秒？1个分区可能适合内存，这就是为什么它这么快的原因170可能不会，所以性能会慢很多，很可能是数小时。您的查询需要来自所有分区的所有数据，还是在查找特定的行？在这种情况下，索引可能会有所帮助。如果不按小时过滤，为什么选择按小时分区？您能展示一下您的表布局并给出典型查询的示例吗？我的表模式只有3列。组名、日期和消息。要查看某个组的消息，网站用户需要选择一个组名，这是必需的，并要求查看该组的消息。他还需要选择一个时间框架。但这一时限仅为1周。我的索引基于组id和时间戳。所以，查询可以利用索引。我唯一的问题是时间戳可以跨越整个170个分区。那就是，我猜是问题所在。如果有足够多的组，那么也可以基于组进行分区，但要确保最后不会有太多分区。在这种情况下，最好将基于时间的分区减少到每天一次，但您必须通过实验确定最有效的方法。我有大约100万个组。我可以使用组校验和创建大约100个分区。基于组校验和，我可以插入到该分区中。如果我使用这种方法，我的select查询将更快，因为它们只需要查看1个分区。但是删除查询的速度会慢一些。由于我们只保留1周的数据，在第8天，我们将删除第1天的数据，这意味着删除查询将命中所有分区。在我以前的方法中，删除查询只会命中几个分区，并且可以删除整个分区。