我们正在使用Postgres 11运行一个系统,我们使用ID实现分区,这对我们来说是最方便的,但它产生了许多分区(目前超过1000个,预计在未来5年内将达到10000 )。我们每月生成3000万行,索引很重。分区行从不更新,我们的查询总是针对单个分区。
现在我们遇到了一个问题,我们用尽了最大允许的锁(cca )。25000)。增加max_locks_per_transaction和max_connections是一个可行的解决方案吗?还是我们应该切换到散列或日期范围分区?如果是的话,最优的分区大小和计数是多少?
发布于 2019-10-07 17:53:09
我们用ID实现分区
这具体是什么意思?列表分区,其中每个列表只有一个成员?身份证是什么?这是父表中的主键吗?您要对子表进行分区吗?
你做了前后的研究,或测试在一个良好的测试环境,以表明你实际上从这个设置从第一?
分区行从不更新,我们的查询总是针对单个分区。现在我们遇到了一个问题,我们用尽了最大允许的锁(cca )。25000)。
如果您不更新,并且查询总是针对单个分区,那么我看不出您将如何耗尽锁。在一次锁定所有分区的操作中发生了什么?25000是max_locks_per_transaction * max_connections
的当前设置(这是不够的),还是要将其增加到这个值?如果已经有25000个数据不足,而且您仍然期望数据增长10倍,那么我会有点担心,仅仅增加数据可能不是一个好的长期解决方案(尽管作为短期解决方案可能不错)。或者至少,我会在测试环境中做一些模拟。
还是我们应该切换到散列或日期范围分区?
分区是不可替代的。如果按ID进行分区会给您带来很大的好处,那么没有理由认为将其更改为日期范围会带来同样的好处。如果不知道收益的来源,我们就无法预测哪些其他方法会保留(或更好)这种好处。
https://dba.stackexchange.com/questions/250411
复制相似问题