Horton

Re: Optimize LISTEN/NOTIFY

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
Cc: Joel Jacobson <joel@compiler.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-05T23:21:17Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Optimize LISTEN/NOTIFY via shared channel map and direct advancement.

  2. Fix incorrect logic for caching ResultRelInfos for triggers


> 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’t be 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 it only handles sleeping listeners. So what I was suggesting is that we should first create some tests, maybe also add a few more statistics, so that we can evaluate different solutions. If a simple implementation that only handles sleeping listeners would 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/