Re: NOTIFY channel

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Perry Smith <pedzsan(at)gmail(dot)com>
Cc: "<pgsql-general(at)postgresql(dot)org>" <pgsql-general(at)postgresql(dot)org>
Subject: Re: NOTIFY channel
Date: 2013-04-26 16:50:55
Message-ID: 13911.1366995055@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Perry Smith <pedzsan(at)gmail(dot)com> writes:
> I'm curious what the design assumptions of the LISTEN / NOTIFY are. For example, would it work to have a thousand LISTEN channels open at the same time or would that be abusing the assumptions that were made? In short, I'm trying to understand if I need a few central LISTEN / NOTIFY channels that then distribute the events out or not.

In the current implementation (since 9.0 IIRC), I don't believe the
total number of channels in use affects the transport mechanism at all.
However, the number that a particular backend is listening on would
affect how fast it can process the messages --- we just run through the
local LISTEN-names list serially for a match to see if an incoming
message is interesting or not. So I'd try to avoid having individual
sessions listening to very large numbers of channels. OTOH, the serial
list scan might still be faster than anything you could easily do in SQL
or plpgsql to sort through messages you were trying to route manually.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2013-04-26 17:25:09 Re: How to find current row number relative to window frame
Previous Message Rafał Pietrak 2013-04-26 16:41:50 Re: is there a way to deliver an array over column from a query window?