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





Mon, 5 Feb 2001 18:25:05 -0800 (PST)
Myron Scott <mscott@sacadia.com>
Re: Using Threads?
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


Tue, 6 Feb 2001 10:20:08 +0100 (CET)
Karel Zak <zakkr@zf.jcu.cz>
Re: Using Threads?

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


Tue, 6 Feb 2001 07:05:04 -0800 (PST)
Myron Scott <mscott@sacadia.com>
Re: Using Threads

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






Tue, 6 Feb 2001 18:31:02 +0100 (CET)
Karel Zak <zakkr@zf.jcu.cz>
Re: Using Threads
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 ...



Tue, 6 Feb 2001 13:47:04 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: Using Threads