@@ -6475,7 +6475,7 @@ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
6475
6475
X-Spam-Status: Yes, hits=5.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM,X_OSIRU_SPAM_SRC version=2.20
6476
6476
X-Spam-Flag: YES
6477
6477
X-Spam-Level: *****
6478
- X-Spam-Checker-Version: SpamAssassin 2.20 (devel $Id: win32,v 1.5 2003/05/23 16:34:35 momjian Exp $)
6478
+ X-Spam-Checker-Version: SpamAssassin 2.20 (devel $Id: win32,v 1.6 2003/11/13 03:45:33 momjian Exp $)
6479
6479
X-Spam-Report: Detailed Report
6480
6480
SPAM: -------------------- Start SpamAssassin results ----------------------
6481
6481
SPAM: This mail is probably spam. The original message has been altered
@@ -9732,3 +9732,113 @@ TIP 3: if posting/reading through Usenet, please send an appropriate
9732
9732
subscribe-nomail command to majordomo@postgresql.org so that your
9733
9733
message can get through to the mailing list cleanly
9734
9734
9735
+ From pgsql-hackers-win32-owner+M201@postgresql.org Tue Nov 11 15:00:07 2003
9736
+ Return-path: <pgsql-hackers-win32-owner+M201@postgresql.org>
9737
+ Received: from noon.pghoster.com ([64.246.0.64])
9738
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id hABK01q22399
9739
+ for <pgman@candle.pha.pa.us>; Tue, 11 Nov 2003 15:00:04 -0500 (EST)
9740
+ Received: from svr1.postgresql.org ([200.46.204.71] helo=postgresql.org)
9741
+ by noon.pghoster.com with esmtp (Exim 4.20)
9742
+ id 1AJefU-0007cv-4L; Tue, 11 Nov 2003 13:59:16 -0600
9743
+ X-Original-To: pgsql-hackers-win32-postgresql.org@localhost.postgresql.org
9744
+ Received: from localhost (unknown [200.46.204.2])
9745
+ by svr1.postgresql.org (Postfix) with ESMTP id 79C28D1B537
9746
+ for <pgsql-hackers-win32-postgresql.org@localhost.postgresql.org>; Tue, 11 Nov 2003 19:59:09 +0000 (GMT)
9747
+ Received: from svr1.postgresql.org ([200.46.204.71])
9748
+ by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
9749
+ with ESMTP id 12494-07
9750
+ for <pgsql-hackers-win32-postgresql.org@localhost.postgresql.org>;
9751
+ Tue, 11 Nov 2003 15:58:39 -0400 (AST)
9752
+ Received: from cuthbert.rcsinc.local (unknown [205.217.85.91])
9753
+ by svr1.postgresql.org (Postfix) with ESMTP id 3798FD1B50D
9754
+ for <pgsql-hackers-win32@postgresql.org>; Tue, 11 Nov 2003 15:58:37 -0400 (AST)
9755
+ Content-Class: urn:content-classes:message
9756
+ MIME-Version: 1.0
9757
+ Content-Type: text/plain;
9758
+ charset="us-ascii"
9759
+ Subject: [pgsql-hackers-win32] CreateProcess vs. CreateThread (was: Committing Resources to Win32)
9760
+ X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
9761
+ Date: Tue, 11 Nov 2003 14:58:23 -0500
9762
+ Message-ID: <303E00EBDD07B943924382E153890E5434AA08@cuthbert.rcsinc.local>
9763
+ Thread-Topic: CreateProcess vs. CreateThread (was: Committing Resources to Win32)
9764
+ Thread-Index: AcOocYEp+LfkD1VdRtuF8Post6o+9gACl8Hg
9765
+ From: "Merlin Moncure" <merlin.moncure@rcsonline.com>
9766
+ To: "Joshua D. Drake" <jd@commandprompt.com>
9767
+ cc: <pgsql-hackers-win32@postgresql.org>
9768
+ X-Virus-Scanned: by amavisd-new at postgresql.org
9769
+ X-Mailing-List: pgsql-hackers-win32
9770
+ Precedence: bulk
9771
+ Sender: pgsql-hackers-win32-owner@postgresql.org
9772
+ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
9773
+ X-AntiAbuse: Primary Hostname - noon.pghoster.com
9774
+ X-AntiAbuse: Original Domain - candle.pha.pa.us
9775
+ X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
9776
+ X-AntiAbuse: Sender Address Domain - postgresql.org
9777
+ Content-Transfer-Encoding: 8bit
9778
+ X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id hABK01q22399
9779
+ Status: OR
9780
+
9781
+ Joshua D. Drake wrote:
9782
+ > >problem is the ipc-daemon which has a tendency to crash. It seems
9783
+ > >slower on writes, but that is strictly anecdotal. With synching off,
9784
+ it
9785
+ > >hums along happily.
9786
+ > >
9787
+ > It is slower on rights, connection startup, limited on connections,
9788
+ > tcp/ip transfer and you should
9789
+ > never run PostgreSQL with sync off unless you are not worried about
9790
+ data
9791
+ > integrity.
9792
+
9793
+ I agree 100%. See notes below.
9794
+
9795
+ > >The perceived win32 process management problems are a total red
9796
+ herring.
9797
+ > >
9798
+ > >
9799
+ > I disagree... read the other posts. CreateProcess does not scale like
9800
+ > CreateThread.
9801
+
9802
+ Here is a good resource comparing process creation on Linux and NT (with
9803
+ source).
9804
+
9805
+ http://www-106.ibm.com/developerworks/linux/library/l-rt7/?t=gr,Redhat=T
9806
+ headsMgt
9807
+
9808
+ NT can create 150 processes/sec (vs. 300+ on Linux 2.4.2). Even with
9809
+ the slower process creation time, most postgres applications will spend
9810
+ a tiny fraction of their time inside process creation. Again, this is
9811
+ much more relevant to a web server than a database server. Compile and
9812
+ run the code supplied in the link if you don't believe me (and I don't
9813
+ expect you to :)).
9814
+
9815
+ My point about cygwin was to try and illustrate that the performance
9816
+ problems wrt postgres on win32 are almost certainly going to be I/O
9817
+ based, not process based (as evidenced by the decent performance with
9818
+ fsync=off), and this is due to the way files are synched (somebody
9819
+ correct me if I'm wrong on this point). I would hate to see you spend a
9820
+ bunch of time implementing threading only to find out you are better off
9821
+ than with the cygwin version. In case I am wrong, it might be
9822
+ informative to fire up a threaded port to see if the end justifies the
9823
+ means. The best apples to apples comparison is to run cygwin/peerdirect
9824
+ fsync=off vs. linux fsync=off. This is not useful in a production
9825
+ sense, but will help tell the relative performance wrt threads vs.
9826
+ processes.
9827
+
9828
+ My gut tells me the proper path is to:
9829
+ 1. Implement no frills process based port to win32 based on (as much as
9830
+ possible) native sources and native build environment.
9831
+ 2. Troubleshoot specific performance problems, which will most likely be
9832
+ on the I/O side. Fixing them may ultimately lead to api level file
9833
+ calls (possibly including asynch I/O) on win32, which may be the only
9834
+ way that platform will ever run postgres as good as on the unix side of
9835
+ things.
9836
+
9837
+ Regards,
9838
+ Merlin
9839
+
9840
+ ---------------------------(end of broadcast)---------------------------
9841
+ TIP 5: Have you checked our extensive FAQ?
9842
+
9843
+ http://www.postgresql.org/docs/faqs/FAQ.html
9844
+
0 commit comments