Re: Using Threads - Mailing list pgsql-hackers

From Myron Scott
Subject Re: Using Threads
Date
Msg-id Pine.GSO.4.10.10102060650250.4153-100000@goldengate.kojoworldwide.com.
Whole thread Raw
In response to Re: Using Threads?  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: Using Threads  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
> 
>  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



pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Implementing an operator in C?
Next
From: Tom Lane
Date:
Subject: Re: optimizer/planner ideas (repost)