Обсуждение: NOTIFY channel
Hi, I'm curious what the design assumptions of the LISTEN / NOTIFY are. For example, would it work to have a thousand LISTENchannels open at the same time or would that be abusing the assumptions that were made? In short, I'm trying to understandif I need a few central LISTEN / NOTIFY channels that then distribute the events out or not. Thank you for your time, Perry
On Fri, Apr 26, 2013 at 11:30 AM, Perry Smith <pedzsan@gmail.com> wrote: > Hi, > > I'm curious what the design assumptions of the LISTEN / NOTIFY are. For example, would it work to have a thousand LISTENchannels open at the same time or would that be abusing the assumptions that were made? In short, I'm trying to understandif I need a few central LISTEN / NOTIFY channels that then distribute the events out or not. Couple quick points about notify: 1) In somewhat recent postgres (9.0) notify implementation was significantly optimized and expanded to include a payload. 2) notify does not work with pgbouncer (yet), although I have in the past had a private pgbouncer with functioning notify. 3) notifies are not delivered until end of transaction, which is sometimes useful, sometimes annoying 4) delivery of notifications is 'best effort', but that effort is pretty much always successful. 5) listener's in the range of 1000's is ok. but don't be afraid to think about using payload and/or putting specific instructions into a table that the client listener acts on after receiving notify. merlin
Perry Smith <pedzsan@gmail.com> writes: > I'm curious what the design assumptions of the LISTEN / NOTIFY are. For example, would it work to have a thousand LISTENchannels open at the same time or would that be abusing the assumptions that were made? In short, I'm trying to understandif 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
"
2) notify does not work with pgbouncer (yet), although I have in the
past had a private pgbouncer with functioning notify.
On Friday, April 26, 2013, Merlin Moncure wrote:
2) notify does not work with pgbouncer (yet), although I have in the
past had a private pgbouncer with functioning notify.
"
Is there a plan to make it work?
Actually - stupid question - probably not important... But good to know...
Listen connection doesn't need to work via pgbouncer...
Thanks,
Misa
On Friday, April 26, 2013, Merlin Moncure wrote:
On Fri, Apr 26, 2013 at 11:30 AM, Perry Smith <pedzsan@gmail.com> wrote:
> Hi,
>
> 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.
Couple quick points about notify:
1) In somewhat recent postgres (9.0) notify implementation was
significantly optimized and expanded to include a payload.
2) notify does not work with pgbouncer (yet), although I have in the
past had a private pgbouncer with functioning notify.
3) notifies are not delivered until end of transaction, which is
sometimes useful, sometimes annoying
4) delivery of notifications is 'best effort', but that effort is
pretty much always successful.
5) listener's in the range of 1000's is ok. but don't be afraid to
think about using payload and/or putting specific instructions into a
table that the client listener acts on after receiving notify.
merlin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general