On Mon, Jul 21, 2025, at 00:06, Rishu Bagga wrote: >> "Joel Jacobson" <j...@compiler.org> writes: >> >> Unfortunately, the author of [1] jumped to conclusion and assumed >> the global lock was the problem. I'm quite sure it is probably not, >> because: >> >> We know for sure, that current users do LISTEN and NOTIFY >> in the same database. And there is no point in doing NOTIFY >> unless you also do LISTEN. > > I agree that, in practice, there is likely no use of NOTIFY without > LISTEN. That being said, I disagree that the global lock is not at > least one of the bottlenecks from a performance perspective. > > The global lock is not released until after the call to > RecordTransactionCommit and the reset of CommitTransaction. So if > there are multiple transactions sending notifications, each must > become durable before the next can proceed, which introduces a > significant bottleneck. > > This becomes especially expensive in environments where compute and > storage are separated, such as certain cloud-based variants of Postgres.
Can you please share the benchmark script and pgbench commands from your initial post? When you skipped the global lock, TPS went from max 190k to max 350k. Based how high these TPS are, I would guess you're not doing LISTEN in your benchmark, but only NOTIFY? Since there is no point of just doing NOTIFY if nobody is LISTENing, a realistic benchmark would also need to do LISTEN. What you will then see is that TPS will be severely impacted, and the gains from removing the global exclusive lock will drown in the huge cost for all the syscalls. On my end, I will work on reducing the expensive syscalls, which I believe is the current bottleneck. Once that's fixed though, the next bottleneck might be the global exclusive lock, so I think it's great your working on improving that as well. /Joel
