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

Sorry for the late response to this, but I've been caught up in
merging TCQ to the 7.3.2 code base.

BTW, an announcement for those interested. We'll be doing a
demonstration of TelegraphCQ during the ACM SIGMOD Conference in
June. This year's SIGMOD is held in San Diego as part of the ACM FCRC
(Federated Computer Research Conf) - visit http://www.sigmod.org for
more details. SIGMOD runs from June 8-12 2003. 

All pgsql hackers (and others) are cordially invited :-) 

Do drop us an email if you're planning to show up. 

>>>>> "Sean" == Sean Chittenden <sean@chittenden.org> writes:
   Sean> You can #ifdef abstract things so that select() and poll()   Sean> work if available.  Though now that I think
aboutit, a   Sean> queue that existed completely in userland would be   Sean> better... an shm implementation that's
abstractedwould be   Sean> ideal, but shm is a precious resource and can't scale all   Sean> that big.  A shared mmap()
region,however, is much less   Sean> scarce and can scale much higher.  mmap() + semaphore as a   Sean> gate to a queue
wouldbe ideal, IMHO.
 

As part of our TelegraphCQ work, we've implemented a generic userland
queue. We support blocking/non-blocking operation at both
enqueue/dequeue time as well as different forms of latching. 

The queue can also live in shared memory, for which we use a new
Shared Memory MemoryContext. This is implemented using libmm - a
memory management library that's came out of the Apache project.

Our current released version is based on the 7.2.1 source
base. However, our internal CVS tip is based on 7.3.2 - we had to make
a few changes to the shm allocator - one more function that's part of
a MemoryContext.

(We can afford to be slightly more profligate in our use of shared
memory as we process all concurrently executing streaming queries in a
single monster query plan. New queries are dynamically folded into a
running query plan on the fly. Since streams represent append-only
data we play fast and loose with transaction isolation ...)

The current version of the code is available at: 
    http://telegraph.cs.berkeley.edu/telegraphcq 

If there is interest, we would love to contribute our queue
infrastructure to PostgreSQL. In fact, we'd love to contribute any of
our stuff that the pgsql folks find interesting/useful.

Our motivations are two-fold:
 (1) We'd like to give back to the pgsql community.
 (2) It's in our interest if things like the Queue/ShMem stuff is part of pgsql as it means one less of a merge hassle
infuture.
 

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh