On Fri, Jul 18, 2025, at 08:46, Joel Jacobson wrote: > However, for cases when up to K backends listen on the same channel > (multicast), > my patch and benchmark in the other thread suggests we can achieve massive > improvements of parallelization of both LISTEN/UNLISTEN as well as NOTIFY > without introducing that much extra complexity. > > Do we find this goal worth pursuing on its own? > > Or should we only focus on exposing a new third parameter to pg_notify() > to indicate out-of-order delivery?
I guess the best would be if we could do both, i.e. improve existing use-cases as well as out-of-order delivery per notification, within acceptable levels of increased complexity? One thing I wonder though, that I haven't yet benchmarked, is if even more parallelization than what my in-order optimizations of NOTIFY already achives, would actually significantly improve parallelization of real workloads, where you do some actual DML in the same txn that you send a NOTIFY. My in-order optimizations now scale to 3000 tps at 1000 connections. I wonder if PostgreSQL really can push that much DML tps, or if the serialization effect of LISTEN/NOTIFY would be marginal to other serialization caused by the DML. /Joel
