尼古拉·萨莫赫瓦洛夫：#PostgresMarathon 2-010：准备语句与分区表锁爆炸，第二部分
内容提要
在#PostgresMarathon 2-009中，我们分析了锁管理器在处理准备语句和分区表时的表现。第六次调用时，锁的数量从8个激增至52个，原因是规划阶段未能进行分区修剪。尽管运行时修剪移除了11个分区，但仍锁定了所有12个分区。
关键要点
-
在#PostgresMarathon 2-009中，分析了锁管理器在处理准备语句和分区表时的表现。
-
第六次调用时，锁的数量从8个激增至52个，原因是规划阶段未能进行分区修剪。
-
尽管运行时修剪移除了11个分区，但仍锁定了所有12个分区。
-
在#PostgresMarathon 2-008中，研究了未分区表的代码流，发现相同的模式，但在第六次调用中未使用高效的规划时间分区修剪。
-
在第六次调用中，规划器在构建通用计划时未能进行分区修剪，导致锁定所有分区。
-
由于缺少绑定参数，分区修剪失败，导致所有12个分区和36个索引被打开并锁定。
-
第六次调用的执行过程总结：构建通用计划时无法在规划时间进行修剪，锁定了所有52个关系。
延伸解读
锁管理器的挑战
在处理准备语句和分区表时，锁管理器面临显著挑战。第六次调用中，锁的数量激增至52个，主要是由于规划阶段未能有效进行分区修剪。这一现象提示开发者在设计数据库查询时，需特别关注锁的管理，以避免性能瓶颈。
分区修剪的重要性
分区修剪在提高查询效率方面至关重要。尽管运行时修剪成功移除了11个分区，但由于缺少绑定参数，规划阶段未能进行有效修剪，导致所有12个分区被锁定。开发者应确保在查询中提供必要的参数，以优化锁的使用和查询性能。
通用计划的局限性
在第六次调用中，使用通用计划时未能进行分区修剪，导致所有分区被锁定。这表明通用计划在某些情况下可能不如定制计划高效。开发者在选择计划类型时，应考虑查询的复杂性和分区策略，以确保最佳性能。
延伸问答
在第六次调用中，为什么锁的数量会从8个激增至52个？
因为在规划阶段未能进行分区修剪，导致所有12个分区和36个索引被锁定。
什么是分区修剪，它在第六次调用中为何失败？
分区修剪是优化查询以减少不必要的分区访问的过程。在第六次调用中，由于缺少绑定参数，分区修剪失败，导致所有分区被锁定。
在#PostgresMarathon 2-008中发现了什么模式？
在#PostgresMarathon 2-008中，研究了未分区表的代码流，发现与分区表相似的模式，但未使用高效的规划时间分区修剪。
第六次调用的执行过程是怎样的？
第六次调用的执行过程包括获取规划器锁、决定使用通用计划、构建通用计划以及由于分区修剪失败而锁定所有分区和索引。
为什么在第六次调用中仍然锁定了所有12个分区？
尽管运行时修剪移除了11个分区，但由于规划阶段未能进行分区修剪，仍然锁定了所有12个分区。
在构建通用计划时，规划器是如何决定使用通用计划的？
规划器通过比较自定义计划的数量和成本来决定，如果自定义计划少于5个且通用计划成本低于平均自定义成本，则使用通用计划。
