@@ -510,3 +510,71 @@ official PostgreSQL and if you spending time on relevant things (IMHO).
510510
511511
512512
513+ From pgsql-hackers-owner+M4304@postgresql.org Tue Feb 6 10:24:21 2001
514+ Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
515+ by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA22027
516+ for <pgman@candle.pha.pa.us>; Tue, 6 Feb 2001 10:24:20 -0500 (EST)
517+ Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
518+ by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f16FOBx97182;
519+ Tue, 6 Feb 2001 10:24:11 -0500 (EST)
520+ (envelope-from pgsql-hackers-owner+M4304@postgresql.org)
521+ Received: from goldengate.kojoworldwide.com. ([216.133.4.130])
522+ by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f16FLWx96814
523+ for <pgsql-hackers@postgresql.org>; Tue, 6 Feb 2001 10:21:33 -0500 (EST)
524+ (envelope-from mscott@sacadia.com)
525+ Received: from localhost (localhost [127.0.0.1])
526+ by goldengate.kojoworldwide.com. (8.9.1b+Sun/8.9.2) with ESMTP id HAA04170;
527+ Tue, 6 Feb 2001 07:05:04 -0800 (PST)
528+ Date: Tue, 6 Feb 2001 07:05:04 -0800 (PST)
529+ From: Myron Scott <mscott@sacadia.com>
530+ X-Sender: mscott@goldengate.kojoworldwide.com.
531+ To: Karel Zak <zakkr@zf.jcu.cz>
532+ cc: pgsql-hackers@postgresql.org
533+ Subject: Re: [HACKERS] Using Threads
534+ In-Reply-To: <Pine.LNX.3.96.1010206101030.20355B-100000@ara.zf.jcu.cz>
535+ Message-ID: <Pine.GSO.4.10.10102060650250.4153-100000@goldengate.kojoworldwide.com.>
536+ MIME-Version: 1.0
537+ Content-Type: TEXT/PLAIN; charset=US-ASCII
538+ Precedence: bulk
539+ Sender: pgsql-hackers-owner@postgresql.org
540+ Status: OR
541+
542+
543+ >
544+ > Sorry I haven't time to see and test your experiment,
545+ > but I have a question. How you solve memory management?
546+ > The current mmgr is based on global variable
547+ > CurrentMemoryContext that is very often changed and used.
548+ > Use you for this locks? If yes it is probably problematic
549+ > point for perfomance.
550+ >
551+ > Karel
552+ >
553+
554+ There are many many globals I had to work around including all the memory
555+ management stuff. I basically threw everything into and "environment"
556+ variable which I stored in a thread specific using thr_setspecific.
557+
558+ Performance is acually very good for what I am doing. I was able to batch
559+ commit transactions which cuts down on fsync calls, use prepared
560+ statements from my client using CORBA, and the various locking calls for
561+ the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did
562+ some performance tests for inserts
563+
564+ 20 clients, 900 inserts per client, 1 insert per transaction, 4 different
565+ tables.
566+
567+ 7.0.2 About 10:52 average completion
568+ multi-threaded 2:42 average completion
569+ 7.1beta3 1:13 average completion
570+
571+ If I increased the number of inserts per transaction, multi-threaded got
572+ closer to 7.1 for inserts. I haven't tested other other types of
573+ commands
574+ yet.
575+
576+
577+ Myron Scott
578+ mkscott@sacadia.com
579+
580+