On Fri, Jul 18, 2025, at 03:28, Tom Lane wrote: > So I sympathize with concerns about how well the notification code > scales, but I think you're going to have to do a ton more work than > this to get to anything that would pass muster to get committed. > In particular, I'd really want to see something that involves > explicitly opting-into out-of-order delivery on a per-NOTIFY basis, > because anything else will break too many applications. The > underlying queue mechanism is going to need a serious rethink, too. > My guess is that we'd need to move to something involving multiple > queues rather than just one, and I'm not very sure how that ought > to work. (But perhaps queuing in-order notifications separately > from not-guaranteed-in-order notifications would help? Or maybe > the latter should be transmitted in some other way entirely.)
I agree opting-into out-of-order delivery on a per-NOTIFY basis sounds like a great idea. For all the exiting users that rely on in-order delivery, and those who are not really sure they would dare to make the switch, do we want to try to do something to improve their use-cases? It doesn't seem possible to do better than what we already do when all backends listen on the same channel. 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? /Joel
