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

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

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

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