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
