Re: LISTEN/NOTIFY benchmarks? - Mailing list pgsql-hackers

From Sean Chittenden
Subject Re: LISTEN/NOTIFY benchmarks?
Date
Msg-id 20030430012604.GB94932@perrin.int.nxad.com
Whole thread Raw
In response to Re: LISTEN/NOTIFY benchmarks?  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: LISTEN/NOTIFY benchmarks?  (Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>)
List pgsql-hackers
> > > 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?
> > 
> > <brainfart_for_the_archives> 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)....  </brainfart_for_the_archives>
> 
> 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 by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: LISTEN/NOTIFY benchmarks?
Next
From: Tatsuo Ishii
Date:
Subject: Re: current breakage with PGCLIENTENCODING