LISTEN/NOTIFY benchmarks?

Поиск
Список
Период
Сортировка
От prashanth@jibenetworks.com
Тема LISTEN/NOTIFY benchmarks?
Дата
Msg-id 20030429011439.GA1692@prashanth.jibenetworks.com
обсуждение исходный текст
Ответы Re: LISTEN/NOTIFY benchmarks?
Re: LISTEN/NOTIFY benchmarks?
Re: LISTEN/NOTIFY benchmarks?
Список 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 по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Please, apply patch for current CVS
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: How about an am_superuser GUC parameter (non-settable)?