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 по дате отправления: