diff --git a/doc/TODO.detail/thread b/doc/TODO.detail/thread index edf7523a20..9ad1d48d17 100644 --- a/doc/TODO.detail/thread +++ b/doc/TODO.detail/thread @@ -378,3 +378,135 @@ mkscott@sacadia.com +From pgsql-hackers-owner+M4304@postgresql.org Tue Feb 6 10:24:21 2001 +Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA22027 + for ; Tue, 6 Feb 2001 10:24:20 -0500 (EST) +Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28]) + by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f16FOBx97182; + Tue, 6 Feb 2001 10:24:11 -0500 (EST) + (envelope-from pgsql-hackers-owner+M4304@postgresql.org) +Received: from goldengate.kojoworldwide.com. ([216.133.4.130]) + by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f16FLWx96814 + for ; Tue, 6 Feb 2001 10:21:33 -0500 (EST) + (envelope-from mscott@sacadia.com) +Received: from localhost (localhost [127.0.0.1]) + by goldengate.kojoworldwide.com. (8.9.1b+Sun/8.9.2) with ESMTP id HAA04170; + Tue, 6 Feb 2001 07:05:04 -0800 (PST) +Date: Tue, 6 Feb 2001 07:05:04 -0800 (PST) +From: Myron Scott +X-Sender: mscott@goldengate.kojoworldwide.com. +To: Karel Zak +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Using Threads +In-Reply-To: +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +> +> 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 + + +From pgsql-hackers-owner+M4313@postgresql.org Tue Feb 6 12:32:00 2001 +Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA29163 + for ; Tue, 6 Feb 2001 12:31:59 -0500 (EST) +Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28]) + by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f16HVox17454; + Tue, 6 Feb 2001 12:31:51 -0500 (EST) + (envelope-from pgsql-hackers-owner+M4313@postgresql.org) +Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4]) + by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f16HV6x17323 + for ; Tue, 6 Feb 2001 12:31:06 -0500 (EST) + (envelope-from zakkr@zf.jcu.cz) +Received: from localhost (zakkr@localhost) + by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id SAA03980; + Tue, 6 Feb 2001 18:31:02 +0100 +Date: Tue, 6 Feb 2001 18:31:02 +0100 (CET) +From: Karel Zak +To: Myron Scott +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Using Threads +In-Reply-To: +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +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 + + + + + +