Re: Optimize LISTEN/NOTIFY

> On Nov 6, 2025, at 01:51, Arseniy Mukhin <arseniy.mukhin.dev@gmail.com> wrote:
>
> On Wed, Nov 5, 2025 at 12:22 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>
>>
>>
>>> On Nov 2, 2025, at 04:41, Arseniy Mukhin <arseniy.mukhin.dev@gmail.com> wrote:
>>>
>>> This condition seems to be redundant. I would say it should always be
>>> true, otherwise it would mean that somebody allowed the listener to
>>> skip our notification.
>>
>> Hi Arseniy,
>>
>
> Hi Chao,
>
>> Did you read the example I explained in my previous email?
>>
>
> Yes, I read it. Thank you for the example. It shows the case where we
> can fail to apply 'direct advancement'. I think there are several
> cases where it can happen. IIUC all such cases are about lagging
> listeners that failed to catch up with the head before the notifier
> tries to apply 'direct advancement' to them. Your example is about
> listeners that finished reading but didn't update their positions
> because they were stuck on the lock. I think it is also possible that
> the listener can be in the process of reading or even didn't start
> reading at all (for example listener backend is in the active
> transaction at the moment). In these cases we also can't apply direct
> advancement. Don't know if some of these examples are more important,
> maybe some of them can be met more frequently.

Cool, you got my idea. What I was thinking is to handle both sleeping listeners and “slow” listeners. In my view, which
shouldn’tbe too much complicated. 

>
> I think the current version of 'direct advancement' will work good for
> 'sleepy' listeners, but probably can be not very efficient for
> listeners that get notifications frequently, don't know. But maybe
> it's ok, we have optimization that sometimes works and have a quite
> simple implementation.
>

That’s what we don’t know. We now lack a performance test for evaluating how “direct advancement” efficiently helps if
itonly handles sleeping listeners. So what I was suggesting is that we should first create some tests, maybe also add a
fewmore statistics, so that we can evaluate different solutions. If a simple implementation that only handles sleeping
listenerswould have performed good enough, of course we can take it; otherwise we may need to either pursue a better
solution.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/