X-Spam-Status: Yes, hits=5.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM,X_OSIRU_SPAM_SRC version=2.20\r
X-Spam-Flag: YES\r
X-Spam-Level: *****\r
-X-Spam-Checker-Version: SpamAssassin 2.20 (devel $Id: win32,v 1.5 2003/05/23 16:34:35 momjian Exp $)\r
+X-Spam-Checker-Version: SpamAssassin 2.20 (devel $Id: win32,v 1.6 2003/11/13 03:45:33 momjian Exp $)\r
X-Spam-Report: Detailed Report\r
SPAM: -------------------- Start SpamAssassin results ----------------------\r
SPAM: This mail is probably spam. The original message has been altered\r
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
+From pgsql-hackers-win32-owner+M201@postgresql.org Tue Nov 11 15:00:07 2003
+Return-path: <pgsql-hackers-win32-owner+M201@postgresql.org>
+Received: from noon.pghoster.com ([64.246.0.64])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id hABK01q22399
+ for <pgman@candle.pha.pa.us>; Tue, 11 Nov 2003 15:00:04 -0500 (EST)
+Received: from svr1.postgresql.org ([200.46.204.71] helo=postgresql.org)
+ by noon.pghoster.com with esmtp (Exim 4.20)
+ id 1AJefU-0007cv-4L; Tue, 11 Nov 2003 13:59:16 -0600
+X-Original-To: pgsql-hackers-win32-postgresql.org@localhost.postgresql.org
+Received: from localhost (unknown [200.46.204.2])
+ by svr1.postgresql.org (Postfix) with ESMTP id 79C28D1B537
+ for <pgsql-hackers-win32-postgresql.org@localhost.postgresql.org>; Tue, 11 Nov 2003 19:59:09 +0000 (GMT)
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
+ with ESMTP id 12494-07
+ for <pgsql-hackers-win32-postgresql.org@localhost.postgresql.org>;
+ Tue, 11 Nov 2003 15:58:39 -0400 (AST)
+Received: from cuthbert.rcsinc.local (unknown [205.217.85.91])
+ by svr1.postgresql.org (Postfix) with ESMTP id 3798FD1B50D
+ for <pgsql-hackers-win32@postgresql.org>; Tue, 11 Nov 2003 15:58:37 -0400 (AST)
+Content-Class: urn:content-classes:message
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset="us-ascii"
+Subject: [pgsql-hackers-win32] CreateProcess vs. CreateThread (was: Committing Resources to Win32)
+X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
+Date: Tue, 11 Nov 2003 14:58:23 -0500
+Message-ID: <303E00EBDD07B943924382E153890E5434AA08@cuthbert.rcsinc.local>
+Thread-Topic: CreateProcess vs. CreateThread (was: Committing Resources to Win32)
+Thread-Index: AcOocYEp+LfkD1VdRtuF8Post6o+9gACl8Hg
+From: "Merlin Moncure" <merlin.moncure@rcsonline.com>
+To: "Joshua D. Drake" <jd@commandprompt.com>
+cc: <pgsql-hackers-win32@postgresql.org>
+X-Virus-Scanned: by amavisd-new at postgresql.org
+X-Mailing-List: pgsql-hackers-win32
+Precedence: bulk
+Sender: pgsql-hackers-win32-owner@postgresql.org
+X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
+X-AntiAbuse: Primary Hostname - noon.pghoster.com
+X-AntiAbuse: Original Domain - candle.pha.pa.us
+X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
+X-AntiAbuse: Sender Address Domain - postgresql.org
+Content-Transfer-Encoding: 8bit
+X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id hABK01q22399
+Status: OR
+
+Joshua D. Drake wrote:
+> >problem is the ipc-daemon which has a tendency to crash. It seems
+> >slower on writes, but that is strictly anecdotal. With synching off,
+it
+> >hums along happily.
+> >
+> It is slower on rights, connection startup, limited on connections,
+> tcp/ip transfer and you should
+> never run PostgreSQL with sync off unless you are not worried about
+data
+> integrity.
+
+I agree 100%. See notes below.
+
+> >The perceived win32 process management problems are a total red
+herring.
+> >
+> >
+> I disagree... read the other posts. CreateProcess does not scale like
+> CreateThread.
+
+Here is a good resource comparing process creation on Linux and NT (with
+source).
+
+http://www-106.ibm.com/developerworks/linux/library/l-rt7/?t=gr,Redhat=T
+headsMgt
+
+NT can create 150 processes/sec (vs. 300+ on Linux 2.4.2). Even with
+the slower process creation time, most postgres applications will spend
+a tiny fraction of their time inside process creation. Again, this is
+much more relevant to a web server than a database server. Compile and
+run the code supplied in the link if you don't believe me (and I don't
+expect you to :)).
+
+My point about cygwin was to try and illustrate that the performance
+problems wrt postgres on win32 are almost certainly going to be I/O
+based, not process based (as evidenced by the decent performance with
+fsync=off), and this is due to the way files are synched (somebody
+correct me if I'm wrong on this point). I would hate to see you spend a
+bunch of time implementing threading only to find out you are better off
+than with the cygwin version. In case I am wrong, it might be
+informative to fire up a threaded port to see if the end justifies the
+means. The best apples to apples comparison is to run cygwin/peerdirect
+fsync=off vs. linux fsync=off. This is not useful in a production
+sense, but will help tell the relative performance wrt threads vs.
+processes.
+
+My gut tells me the proper path is to:
+1. Implement no frills process based port to win32 based on (as much as
+possible) native sources and native build environment.
+2. Troubleshoot specific performance problems, which will most likely be
+on the I/O side. Fixing them may ultimately lead to api level file
+calls (possibly including asynch I/O) on win32, which may be the only
+way that platform will ever run postgres as good as on the unix side of
+things.
+
+Regards,
+Merlin
+
+---------------------------(end of broadcast)---------------------------
+TIP 5: Have you checked our extensive FAQ?
+
+ http://www.postgresql.org/docs/faqs/FAQ.html
+
OSDN Git Service
