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 8168CD7226 for ; Thu, 3 Nov 2005 18:13:46 -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 05979-08 for ; Thu, 3 Nov 2005 22:13:44 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 532F5D7215 for ; Thu, 3 Nov 2005 18:13:45 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.13.1/8.13.1) with ESMTP id jA3MDh7j009930 for ; Thu, 3 Nov 2005 22:13:43 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.13.1/8.13.1/Submit) id jA3LkcMj000589 for pgsql-performance@postgresql.org; Thu, 3 Nov 2005 21:46:38 GMT (envelope-from news) From: "Qingqing Zhou" X-Newsgroups: pgsql.performance Subject: Re: insert performance for win32 Date: Thu, 3 Nov 2005 16:46:52 -0500 Organization: Hub.Org Networking Services Lines: 29 Message-ID: References: <6EE64EF3AB31D5448D0007DD34EEB3417DD79B@Herge.rcsinc.local> X-Complaints-To: usenet@news.hub.org X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=-1.414 required=5 tests=[ALL_TRUSTED=-1.44, AWL=0.026] X-Spam-Score: -1.414 X-Spam-Level: X-Archive-Number: 200511/61 X-Sequence-Number: 15318 ""Merlin Moncure"" wrote > > Running from remote, Time progression is: > First 50k: 20 sec > Second : 29 sec > [...] > final: : 66 sec > This may due to the maintainence cost of a big transaction, I am not sure ... Tom? > so, clear upward progression of time/rec. Initial time is 2.5k > inserts/sec which is decent but not great for such a narrow table. CPU > time on server starts around 50% and drops in exact proportion to insert > performance. My earlier gprof test also suggest there is no smoking gun > sucking down all the cpu time. > Not to 100%, so this means the server is always starving. It is waiting on something -- of couse not lock. That's why I think there is some problem on network communication. Another suspect will be the write - I knwo NTFS system will issue an internal log when extending a file. To remove the second suspect, I will try to hack the source to do a "fake" write ... Regards, Qingqing