Re: Optimize LISTEN/NOTIFY
| От | Tom Lane | 
|---|---|
| Тема | Re: Optimize LISTEN/NOTIFY | 
| Дата | |
| Msg-id | 1547585.1760645808@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | Re: Optimize LISTEN/NOTIFY ("Joel Jacobson" <joel@compiler.org>) | 
| Ответы | 
                	
            		Re: Optimize LISTEN/NOTIFY
            		
            		 Re: Optimize LISTEN/NOTIFY  | 
		
| Список | pgsql-hackers | 
"Joel Jacobson" <joel@compiler.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
		
	В списке pgsql-hackers по дате отправления: