LISTEN/NOTIFY benchmarks? - Mailing list pgsql-hackers

From prashanth@jibenetworks.com
Subject LISTEN/NOTIFY benchmarks?
Date
Msg-id 20030429011439.GA1692@prashanth.jibenetworks.com
Whole thread Raw
Responses Re: LISTEN/NOTIFY benchmarks?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: LISTEN/NOTIFY benchmarks?  (Hannu Krosing <hannu@tm.ee>)
Re: LISTEN/NOTIFY benchmarks?  (Sean Chittenden <sean@chittenden.org>)
List pgsql-hackers
Hi,

I'm looking for information on the scalabality of the LISTEN/NOTIFY
mechanism.  How well does it scale with respect to:

- hundreds of clients registered for LISTENs 
   I guess this translates to hundreds of the corresponding backend   processes receiving SIG_USR2 signals.  The
efficiencyof this is   probably OS-dependent.  Would anyone be in a position to give me   signal delivery benchmarks
forFreeBSD on Unix?
 

- each client registered for thousands of LISTENs
   From a look at backend/commands/async.c, it would seem that each   listening backend would get a signal for *every*
LISTENit   registered for, resulting in thousands of signals to the same   listening backend, instead of only one.
Wouldit help if this was   optimized so that a signal was sent only once?  Again, info on   relevant signal delivery
benchmarkswould be useful.  
 

I'm not an expert on signals, not even a novice, so I might be totally
off base, but it seems like the Async Notification implementation does
not scale.  If it does not, does anyone have a solution for the
problem of signalling a each event in a possibly very large set of
events to a large number of clients?

Thanks,

--prashanth


  



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Please, apply patch for current CVS
Next
From: Peter Eisentraut
Date:
Subject: Re: How about an am_superuser GUC parameter (non-settable)?