Re: LISTEN/NOTIFY benchmarks?
От
Sean Chittenden
Тема
Re: LISTEN/NOTIFY benchmarks?
Дата
Msg-id
20030430012604.GB94932@perrin.int.nxad.com
Ответ на
Re: LISTEN/NOTIFY benchmarks? (Gavin Sherry)
Список
Дерево обсуждения
LISTEN/NOTIFY benchmarks? prashanth@jibenetworks.com
Re: LISTEN/NOTIFY benchmarks? Hannu Krosing <hannu@tm.ee>
Re: LISTEN/NOTIFY benchmarks? prashanth@jibenetworks.com
Re: LISTEN/NOTIFY benchmarks? Tom Lane <tgl@sss.pgh.pa.us>
Re: LISTEN/NOTIFY benchmarks? prashanth@jibenetworks.com
Re: LISTEN/NOTIFY benchmarks? Tom Lane <tgl@sss.pgh.pa.us>
Re: LISTEN/NOTIFY benchmarks? prashanth@jibenetworks.com
Re: LISTEN/NOTIFY benchmarks? Tom Lane <tgl@sss.pgh.pa.us>
Re: LISTEN/NOTIFY benchmarks? Sean Chittenden <sean@chittenden.org>
Re: LISTEN/NOTIFY benchmarks? Gavin Sherry <swm@linuxworld.com.au>
Re: LISTEN/NOTIFY benchmarks? Sean Chittenden <sean@chittenden.org>
Re: LISTEN/NOTIFY benchmarks? Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>
Re: LISTEN/NOTIFY benchmarks? Sean Chittenden <sean@chittenden.org>
Re: LISTEN/NOTIFY benchmarks? Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>
Re: LISTEN/NOTIFY benchmarks? Sean Chittenden <sean@chittenden.org>
Re: LISTEN/NOTIFY benchmarks? Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>
> > > 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? > > > > Hrm.... I should see about porting > > kqueue/kevent as a messaging buss for the listen/notify bits to > > postgresql... that does scale and it scales well to tens of > > thousands of connections a second (easily over 60K, likely closer > > to 1M is the limit).... > > Except that it is FreeBSD specific -- being system calls and all -- > if I remember correctly. If you're going to move to a system like > that, which is a good idea, best move to a portable system. You can #ifdef abstract things so that select() and poll() work if available. Though now that I think about it, a queue that existed completely in userland would be better... an shm implementation that's abstracted would be ideal, but shm is a precious resource and can't scale all that big. A shared mmap() region, however, is much less scarce and can scale much higher. mmap() + semaphore as a gate to a queue would be ideal, IMHO. I shouldn't be posti^H^H^H^H^Hrambling though, haven't slept in 72hrs. :-/ *stops reading email* -sc -- Sean Chittenden
В списке pgsql-hackers по дате отправления