Re: LISTEN/NOTIFY benchmarks?

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(at)chittenden(dot)org> writes:

Sean> You can #ifdef abstract things so that select() and poll()
Sean> work if available. Though now that I think about it, a
Sean> queue that existed completely in userland would be
Sean> better... an shm implementation that's abstracted would 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 would be 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 in future.

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