很明显，在会话上设置synchronous_commit OFF - 其超级罕见的缺点（据称在服务器崩溃的情况下会丢失提交的事务） - 很好，可以提高这些会话的性能，因为它们不必等待 WAL刷新到磁盘。
但是，我无法理解的是这如何影响在同一时间窗口内提交的所有会话synchronous_commit ON。
据我了解，synchronous_commit OFF产生 WAL 的会话与拥有 WAL 的会话一样多ON（甚至更多，因为它们在同一时间完成更多工作，因为它们不必等待 WALWrite）。那么拥有它的会话ON会像所有会话都拥有它一样慢吗ON？
场景 1：10 个执行大量 DML 的会话拥有它ON，10 个会话拥有它OFF。
场景 2：20 个执行大量 DML 的会话ON。
我认为会发生什么：在场景 1 中，10 个会话OFF产生的 WAL 比场景 2 中更多，因此会话ON等待 WALWrite 的时间比场景 1 中更长。
我是否正确理解每次提交总是等待所有当前（xid<=自己的xid）WAL 数据被写入而不仅仅是“它自己的”WAL 数据？
您假设会话有无限量的工作要做。更一般地说，会话有一个特定的任务要完成，一旦完成，它就完成了。它不会因为提前完成了原来的任务而四处发明新任务。
你对它进行了基准测试并看到了吗？这将取决于您的存储系统以及每笔交易的大小等因素。
您的理解是正确的，但含义可能不正确。一般来说，瓶颈不在于写入的 WAL 字节数，而在于等待所有数据已安全到达稳定介质的确认。在 10 个块中写入和刷新给定数量的字节将比在 20 个块中写入和刷新相同数量的字节更少的工作（和更少的时间），除非该字节数可能非常大。
如果我正在同步冲水，但碰巧我在其他人开始冲水后才准备开始冲水，那么在他们完成冲水之前我无法开始冲水。如果它们是异步的，那么我可以在准备就绪后立即开始刷新（其中将包括它们的数据和我的数据），从而更快地完成。