Re: LISTEN/NOTIFY benchmarks?
От | prashanth@jibenetworks.com |
---|---|
Тема | Re: LISTEN/NOTIFY benchmarks? |
Дата | |
Msg-id | 20030429195400.GB3037@prashanth.jibenetworks.com обсуждение исходный текст |
Ответ на | Re: LISTEN/NOTIFY benchmarks? (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: LISTEN/NOTIFY benchmarks?
|
Список | pgsql-hackers |
On Tue, Apr 29, 2003 at 10:10:47AM +0300, Hannu Krosing wrote: > prashanth@jibenetworks.com kirjutas T, 29.04.2003 kell 04:14: > > - 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* LISTEN it > > registered for, resulting in thousands of signals to the same > > listening backend, instead of only one. > > But as the signals are usually generated async, you have no way to know > if a particular backend has already received a signal. > > Or do you mean some mechanism that remembers "signals sent" in some > shared structure that the receiving backend can then clear when it > actually receives the signal ? No, I meant that a listening backend process would be sent multiple signals from a notifying process, *in the inner loop* of backend/commands/async.c:AtCommit_Notify(). If the listening backend had registered tens of thousands of LISTENs, it would be sent an equivalent number of signals during a single run of AtCommit_Notify(). I'm not sure what the cost of this is, since I'm not sure how signal delivery works, but the tens of thousands of system calls cannot be very cheap. --prashanth
В списке pgsql-hackers по дате отправления: