From: | Myron Scott <mscott(at)sacadia(dot)com> |
---|---|
To: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Using Threads |
Date: | 2001-02-06 15:05:04 |
Message-ID: | Pine.GSO.4.10.10102060650250.4153-100000@goldengate.kojoworldwide.com. |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sacadia(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-02-06 15:47:56 | Re: optimizer/planner ideas (repost) |
Previous Message | Thomas Lockhart | 2001-02-06 14:14:33 | Re: Implementing an operator in C? |