Thread

1. Re: Using Threads?

   Myron Scott <mscott@sacadia.com> — 2001-02-06T02:25:05Z

   I have put a new version of my multi-threaded
   postgresql experiment at
   
   http://www.sacadia.com/mtpg.html
   
   This one actually works.  I have added a server
   based on omniORB, a CORBA 2.3 ORB from ATT.  It
      is much smaller than TAO and uses the thread per
   connection model.  I haven't added the java side
   of the JNI interface yet but the C++ side is there.
   
   It's still not stable but it is much better than
   the last.
   
   Myron Scott
   mkscott@sacadia.com
   
   
   
   
   
   

2. Re: Using Threads?

   Karel Zak <zakkr@zf.jcu.cz> — 2001-02-06T09:20:08Z

   On Mon, 5 Feb 2001, Myron Scott wrote:
   
   > I have put a new version of my multi-threaded
   > postgresql experiment at
   > 
   > http://www.sacadia.com/mtpg.html
   > 
   > This one actually works.  I have added a server
   > based on omniORB, a CORBA 2.3 ORB from ATT.  It
   >    is much smaller than TAO and uses the thread per
   > connection model.  I haven't added the java side
   > of the JNI interface yet but the C++ side is there.
   > 
   > It's still not stable but it is much better than
   > mkscott@sacadia.com
   
    Sorry I haven't time to see and test your experiment,
   but I have a question. How you solve memory management?
   The current mmgr is based on global variable 
   CurrentMemoryContext that is very often changed and used.
    Use you for this locks? If yes it is probably problematic
   point for perfomance.
   
   			Karel
   
   
   

3. Re: Using Threads

   Myron Scott <mscott@sacadia.com> — 2001-02-06T15:05:04Z

   > 
   >  Sorry I haven't time to see and test your experiment,
   > but I have a question. How you solve memory management?
   > The current mmgr is based on global variable 
   > CurrentMemoryContext that is very often changed and used.
   >  Use you for this locks? If yes it is probably problematic
   > point for perfomance.
   > 
   > 			Karel
   > 
   
   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.
   
   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
   
   If I increased the number of inserts per transaction, multi-threaded got
   closer to 7.1 for inserts.  I haven't tested other other types of
   commands
   yet.
   
   
   Myron Scott
   mkscott@sacadia.com
   
   
   

4. Re: Using Threads

   Karel Zak <zakkr@zf.jcu.cz> — 2001-02-06T17:31:02Z

   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).
   
   		Karel
   
   
   
   
   
   
   

5. Re: Using Threads

   Marc Fournier <scrappy@hub.org> — 2001-02-06T17:47:04Z

   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 ...