From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Joel Jacobson" <joel(at)compiler(dot)org> |
Cc: | "Chao Li" <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize LISTEN/NOTIFY |
Date: | 2025-10-16 20:16:48 |
Message-ID: | 1547585.1760645808@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Joel Jacobson" <joel(at)compiler(dot)org> writes:
> On Thu, Oct 16, 2025, at 20:16, Joel Jacobson wrote:
>> Building pendingNotifyChannels is O(N^2) yes, but how large N is
>> realistic here?
> I agree this looks like a real problem, since I guess it's not
> completely unthinkable someone might have
> some kind of trigger on a table, that could fire off NOTIFY
> for each row, possibly causing hundreds of thousands of
> notifies in the same db txn.
We already de-duplicate identical NOTIFY operations for exactly that
reason (cf. AsyncExistsPendingNotify). However, non-identical NOTIFYs
obviously can't be merged.
I wonder whether we could adapt that de-duplication logic so that
it produces a list of unique channel names in addition to a list
of unique NOTIFY events. One way could be a list/hashtable of
channels used, and for each one a list/hashtable of unique payloads,
rather than the existing single-level list/hashtable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2025-10-16 20:39:47 | Re: postgres_fdw: Use COPY to speed up batch inserts |
Previous Message | Robert Haas | 2025-10-16 20:15:54 | Re: RFC: Logging plan of the running query |