Postgres在执行简单SELECT时，前五次使用自定义计划，锁定表及所有索引。第六次切换到通用计划，但仍锁定所有索引。第七次开始仅锁定表。这是由于规划器锁和执行器锁的机制不同所致。

在2023-2024年，PostgresAI的客户在大机器上遇到LWLock:LockManager争用问题。PG18发布后，Denis Morozov在16个vCPU的虚拟机上成功重现了该问题。调整max_locks_per_transaction后发现其对规划时间有影响。计划对PG17进行基准测试，并研究小型机器是否会出现类似问题。

锁管理器负责管理重型锁，事务结束时释放。SELECT操作会锁定表及其索引。Postgres 8.2之前，所有锁信息存储在一个哈希表中，导致竞争。为缓解此问题，哈希表被分为16个分区。2011年引入快速路径锁，减少竞争并提升性能。Postgres 18进一步优化以应对分区带来的挑战。

PostgreSQL用户在Lock Manager方面遇到了争用问题，导致性能下降。这个问题已经被GitLab和Midjourney等多家公司观察到。问题与轻量级锁有关，高事务率和分区数量等因素加剧了问题。缓解策略包括增加容量，应用层缓存，删除不必要的索引，并确保对分区表进行适当的查询优化。尽管出现了这些问题，PostgreSQL仍然是一种受欢迎且可扩展的数据库，正在进行改进Lock Manager可扩展性的讨论。