@@ -378,3 +378,135 @@ mkscott@sacadia.com
378
378
379
379
380
380
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