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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Transform groups
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LISTEN/NOTIFY benchmarks?