Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit d3aa664

Browse files
committed
Add.
1 parent a0b9ffb commit d3aa664

File tree

1 file changed

+132
-0
lines changed

1 file changed

+132
-0
lines changed

doc/TODO.detail/thread

Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -378,3 +378,135 @@ mkscott@sacadia.com
378378

379379

380380

381+
From pgsql-hackers-owner+M4304@postgresql.org Tue Feb 6 10:24:21 2001
382+
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
383+
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA22027
384+
for <pgman@candle.pha.pa.us>; Tue, 6 Feb 2001 10:24:20 -0500 (EST)
385+
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
386+
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f16FOBx97182;
387+
Tue, 6 Feb 2001 10:24:11 -0500 (EST)
388+
(envelope-from pgsql-hackers-owner+M4304@postgresql.org)
389+
Received: from goldengate.kojoworldwide.com. ([216.133.4.130])
390+
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f16FLWx96814
391+
for <pgsql-hackers@postgresql.org>; Tue, 6 Feb 2001 10:21:33 -0500 (EST)
392+
(envelope-from mscott@sacadia.com)
393+
Received: from localhost (localhost [127.0.0.1])
394+
by goldengate.kojoworldwide.com. (8.9.1b+Sun/8.9.2) with ESMTP id HAA04170;
395+
Tue, 6 Feb 2001 07:05:04 -0800 (PST)
396+
Date: Tue, 6 Feb 2001 07:05:04 -0800 (PST)
397+
From: Myron Scott <mscott@sacadia.com>
398+
X-Sender: mscott@goldengate.kojoworldwide.com.
399+
To: Karel Zak <zakkr@zf.jcu.cz>
400+
cc: pgsql-hackers@postgresql.org
401+
Subject: Re: [HACKERS] Using Threads
402+
In-Reply-To: <Pine.LNX.3.96.1010206101030.20355B-100000@ara.zf.jcu.cz>
403+
Message-ID: <Pine.GSO.4.10.10102060650250.4153-100000@goldengate.kojoworldwide.com.>
404+
MIME-Version: 1.0
405+
Content-Type: TEXT/PLAIN; charset=US-ASCII
406+
Precedence: bulk
407+
Sender: pgsql-hackers-owner@postgresql.org
408+
Status: OR
409+
410+
411+
>
412+
> Sorry I haven't time to see and test your experiment,
413+
> but I have a question. How you solve memory management?
414+
> The current mmgr is based on global variable
415+
> CurrentMemoryContext that is very often changed and used.
416+
> Use you for this locks? If yes it is probably problematic
417+
> point for perfomance.
418+
>
419+
> Karel
420+
>
421+
422+
There are many many globals I had to work around including all the memory
423+
management stuff. I basically threw everything into and "environment"
424+
variable which I stored in a thread specific using thr_setspecific.
425+
426+
Performance is acually very good for what I am doing. I was able to batch
427+
commit transactions which cuts down on fsync calls, use prepared
428+
statements from my client using CORBA, and the various locking calls for
429+
the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did
430+
some performance tests for inserts
431+
432+
20 clients, 900 inserts per client, 1 insert per transaction, 4 different
433+
tables.
434+
435+
7.0.2 About 10:52 average completion
436+
multi-threaded 2:42 average completion
437+
7.1beta3 1:13 average completion
438+
439+
If I increased the number of inserts per transaction, multi-threaded got
440+
closer to 7.1 for inserts. I haven't tested other other types of
441+
commands
442+
yet.
443+
444+
445+
Myron Scott
446+
mkscott@sacadia.com
447+
448+
449+
From pgsql-hackers-owner+M4313@postgresql.org Tue Feb 6 12:32:00 2001
450+
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
451+
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA29163
452+
for <pgman@candle.pha.pa.us>; Tue, 6 Feb 2001 12:31:59 -0500 (EST)
453+
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
454+
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f16HVox17454;
455+
Tue, 6 Feb 2001 12:31:51 -0500 (EST)
456+
(envelope-from pgsql-hackers-owner+M4313@postgresql.org)
457+
Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
458+
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f16HV6x17323
459+
for <pgsql-hackers@postgresql.org>; Tue, 6 Feb 2001 12:31:06 -0500 (EST)
460+
(envelope-from zakkr@zf.jcu.cz)
461+
Received: from localhost (zakkr@localhost)
462+
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id SAA03980;
463+
Tue, 6 Feb 2001 18:31:02 +0100
464+
Date: Tue, 6 Feb 2001 18:31:02 +0100 (CET)
465+
From: Karel Zak <zakkr@zf.jcu.cz>
466+
To: Myron Scott <mscott@sacadia.com>
467+
cc: pgsql-hackers@postgresql.org
468+
Subject: Re: [HACKERS] Using Threads
469+
In-Reply-To: <Pine.GSO.4.10.10102060650250.4153-100000@goldengate.kojoworldwide.com.>
470+
Message-ID: <Pine.LNX.3.96.1010206182112.3799B-100000@ara.zf.jcu.cz>
471+
MIME-Version: 1.0
472+
Content-Type: TEXT/PLAIN; charset=US-ASCII
473+
Precedence: bulk
474+
Sender: pgsql-hackers-owner@postgresql.org
475+
Status: OR
476+
477+
478+
On Tue, 6 Feb 2001, Myron Scott wrote:
479+
480+
> There are many many globals I had to work around including all the memory
481+
> management stuff. I basically threw everything into and "environment"
482+
> variable which I stored in a thread specific using thr_setspecific.
483+
484+
Yes, it's good. I working on multi-thread application server
485+
(http://mape.jcu.cz) and I use for this project some things from PG (like
486+
mmgr), I planning use same solution.
487+
488+
> Performance is acually very good for what I am doing. I was able to batch
489+
> commit transactions which cuts down on fsync calls, use prepared
490+
> statements from my client using CORBA, and the various locking calls for
491+
> the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did
492+
> some performance tests for inserts
493+
>
494+
> 20 clients, 900 inserts per client, 1 insert per transaction, 4 different
495+
> tables.
496+
>
497+
> 7.0.2 About 10:52 average completion
498+
> multi-threaded 2:42 average completion
499+
> 7.1beta3 1:13 average completion
500+
501+
It is very very good for time for 7.1, already look forward to 7.2! :-)
502+
503+
BTW, I not sure if you anytime in future will see threads in
504+
official PostgreSQL and if you spending time on relevant things (IMHO).
505+
506+
Karel
507+
508+
509+
510+
511+
512+

0 commit comments

Comments
 (0)