On Tue, 6 Feb 2001, Karel Zak wrote:
>
> On Tue, 6 Feb 2001, Myron Scott wrote:
>
> > There are many many globals I had to work around including all the memory
> > management stuff. I basically threw everything into and "environment"
> > variable which I stored in a thread specific using thr_setspecific.
>
> Yes, it's good. I working on multi-thread application server
> (http://mape.jcu.cz) and I use for this project some things from PG (like
> mmgr), I planning use same solution.
>
> > Performance is acually very good for what I am doing. I was able to batch
> > commit transactions which cuts down on fsync calls, use prepared
> > statements from my client using CORBA, and the various locking calls for
> > the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did
> > some performance tests for inserts
> >
> > 20 clients, 900 inserts per client, 1 insert per transaction, 4 different
> > tables.
> >
> > 7.0.2 About 10:52 average completion
> > multi-threaded 2:42 average completion
> > 7.1beta3 1:13 average completion
>
> It is very very good for time for 7.1, already look forward to 7.2! :-)
>
> BTW, I not sure if you anytime in future will see threads in
> official PostgreSQL and if you spending time on relevant things (IMHO).
There have been discussions about this, where we still do one process per
client, but the backend of that process would use threads in order to
improve performance on SMP boxes for that one client ...