X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 1C4D8D6824 for ; Fri, 4 Nov 2005 03:29:53 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 24847-02 for ; Fri, 4 Nov 2005 07:29:49 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from cliff.cs.toronto.edu (cliff.cs.toronto.edu [128.100.3.120]) by svr1.postgresql.org (Postfix) with ESMTP id F3332D687B for ; Fri, 4 Nov 2005 03:29:49 -0400 (AST) Received: from eon.cs (eon.cs.toronto.edu [128.100.3.15]) by cliff.cs.toronto.edu (Postfix) with ESMTP id 94C315FD0B; Fri, 4 Nov 2005 02:29:49 -0500 (EST) Received: by eon.cs (Postfix, from userid 1300) id CCFBE698; Fri, 4 Nov 2005 02:29:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by eon.cs (Postfix) with ESMTP id C24FE544; Fri, 4 Nov 2005 02:29:49 -0500 (EST) Date: Fri, 4 Nov 2005 02:29:49 -0500 (EST) From: Qingqing Zhou X-X-Sender: zhouqq@eon.cs To: Tom Lane Cc: Merlin Moncure , pgsql-performance@postgresql.org, Marc Cousin Subject: Re: insert performance for win32 In-Reply-To: <7860.1131062219@sss.pgh.pa.us> Message-ID: References: <6EE64EF3AB31D5448D0007DD34EEB3417DD79B@Herge.rcsinc.local> <7860.1131062219@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.362 required=5 tests=[AWL=-0.117, DNS_FROM_RFC_ABUSE=0.479] X-Spam-Score: 0.362 X-Spam-Level: X-Archive-Number: 200511/67 X-Sequence-Number: 15324 On Thu, 3 Nov 2005, Tom Lane wrote: > > On Unix I get a dead flat line (within measurement noise), both local > loopback and across my LAN. > > after 50000 30.20 sec > after 100000 31.67 sec > after 150000 30.98 sec > after 200000 29.64 sec > after 250000 29.83 sec > Confirmed in Linux. And on a winxp machine(sp2) with server, client together, with (see almost no performance difference) or without my "fake" write, the observation is still hold for both cases: after 50000 25.21 sec after 100000 26.26 sec after 150000 25.23 sec after 200000 26.25 sec after 250000 26.58 sec In both cases, postgres 67% cpu, psql 15~20%, rest: system process. Kernel time is 40+% -- where from? Regards, Qingqing