尼古拉·萨莫赫瓦洛夫：#PostgresMarathon 2-009：预处理语句与分区表锁爆炸，第一部分
内容提要
在#PostgresMarathon 2-008中，预处理语句显著减少了LWLock:LockManager的争用。通过从规划器锁切换到执行器锁，锁的数量从6降至1。测试分区表时，执行6时锁数量从8增至52，但执行7后，使用缓存的通用计划，锁数量显著减少。
关键要点
-
在#PostgresMarathon 2-008中，预处理语句显著减少了LWLock:LockManager的争用。
-
通过从规划器锁切换到执行器锁，锁的数量从6降至1。
-
测试分区表时，执行6时锁数量从8增至52。
-
执行7后，使用缓存的通用计划，锁数量显著减少。
-
创建了一个简单的分区表，包含多个分区。
-
在每个分区上添加了索引，并收集统计信息。
-
在执行1-5时，使用自定义计划，锁数量为8。
-
在执行6时，使用通用计划，锁数量增加到52。
-
执行7及之后，运行时分区修剪使锁数量减少到13。
-
执行器在运行时修剪之前过早获取锁，这是已知的限制。
延伸解读
预处理语句的优势
预处理语句在减少锁争用方面表现出色，尤其是在从规划器锁切换到执行器锁后，锁的数量显著减少。这一变化不仅提高了性能，还降低了系统资源的消耗，适合高并发环境下的数据库操作。
分区表的锁管理挑战
在测试分区表时，锁的数量在执行6时激增至52，显示出分区表在高并发情况下可能带来的锁管理挑战。开发者需要关注分区数量对锁争用的影响，尤其是在数据量大的情况下，可能导致性能瓶颈。
运行时分区修剪的局限性
尽管运行时分区修剪在执行7及之后有效减少了锁的数量，但仍然存在锁获取过早的问题。这意味着即使在优化后，系统仍可能面临不必要的锁争用，开发者应考虑这一限制以优化查询性能。
延伸问答
预处理语句如何减少锁争用？
预处理语句通过从规划器锁切换到执行器锁，显著减少了LWLock:LockManager的争用，锁的数量从6降至1。
分区表在执行时锁的数量变化如何？
在执行6时，分区表的锁数量从8增至52，而在执行7后，使用缓存的通用计划，锁数量显著减少到13。
如何创建一个简单的分区表？
可以使用SQL语句创建分区表，例如：`create table events (event_id bigint, event_time timestamptz, event_data text) partition by range (event_time);`
执行器在运行时修剪的作用是什么？
运行时分区修剪可以减少锁的数量，但由于执行器在修剪之前过早获取锁，仍然会锁定所有分区。
在测试中使用空表有什么意义？
使用空表可以专注于锁行为的研究，而不受查询执行性能的影响，确保测试的可重复性。
执行6和执行7的锁数量有什么区别？
执行6时锁数量为52，而执行7时由于使用缓存的通用计划，锁数量减少到13。
