尼古拉·萨莫赫瓦洛夫：#PostgresMarathon 2-005：Postgres 18的更多LWLock:LockManager基准测试
内容提要
在2023-2024年，PostgresAI的客户在大机器上遇到LWLock:LockManager争用问题。PG18发布后，Denis Morozov在16个vCPU的虚拟机上成功重现了该问题。调整max_locks_per_transaction后发现其对规划时间有影响。计划对PG17进行基准测试，并研究小型机器是否会出现类似问题。
关键要点
-
在2023-2024年，PostgresAI的客户在大机器上遇到LWLock:LockManager争用问题。
-
Denis Morozov在16个vCPU的虚拟机上成功重现了该问题。
-
调整max_locks_per_transaction后发现其对规划时间有影响。
-
计划对PG17进行基准测试，以便进行清晰的比较。
-
对小型机器（如8个vCPU）是否会出现类似问题感到好奇。
-
在max_locks_per_transaction=1024时，未观察到争用问题，最多可添加200个索引。
-
执行时间的增长在max_locks_per_transaction=1024时表现出明显不同。
-
虽然未发现PG18优化本身的缺点，但max_locks_per_transaction过大可能会带来其他问题，值得进一步分析。
延伸问答
什么是LWLock:LockManager争用问题？
LWLock:LockManager争用问题是指在Postgres数据库中，当多个进程尝试访问锁管理器时发生的竞争情况，可能导致性能下降。
Denis Morozov在基准测试中发现了什么？
Denis Morozov在16个vCPU的虚拟机上成功重现了LWLock:LockManager争用问题，并观察到调整max_locks_per_transaction对规划时间的影响。
max_locks_per_transaction的调整对性能有什么影响？
调整max_locks_per_transaction会影响规划时间，当超出快速路径锁槽时，锁管理器会使用主锁表，从而影响性能。
在PG18中，是否观察到LWLock:LockManager争用问题？
在max_locks_per_transaction设置为1024时，未观察到LWLock:LockManager争用问题，最多可以添加200个索引。
未来的基准测试计划是什么？
计划对PG17进行基准测试，以便进行清晰的比较，并可能研究小型机器（如8个vCPU）是否会出现类似问题。
max_locks_per_transaction过大有什么潜在问题？
max_locks_per_transaction过大可能会导致内存消耗增加，并可能带来其他未明确的问题，值得进一步分析。
