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
optimizationsof NOTIFY already achives, would actually significantly improve parallelization of real workloads, where
youdo 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
wouldbe marginal to other serialization caused by the DML.
/Joel
