X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 2E20A9DCF7E for ; Tue, 6 Dec 2005 01:52:38 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 47458-07-2 for ; Tue, 6 Dec 2005 01:52:36 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svr2.postgresql.org (svr2.postgresql.org [65.19.161.25]) by postgresql.org (Postfix) with ESMTP id 968279DCC3B for ; Tue, 6 Dec 2005 01:52:35 -0400 (AST) Received: from fuse6.mailanyone.net (fuse6.mailanyone.net [69.31.1.175]) by svr2.postgresql.org (Postfix) with ESMTP id 55A11F15D7 for ; Tue, 6 Dec 2005 05:52:35 +0000 (GMT) Received: from mailanyone.net by fuse6.mailanyone.net with asmtp (TLSv1:AES256-SHA:256) (MailAnyone extSMTP) id 1EjVkk-0004rR-4C for pgsql-performance@postgresql.org; Mon, 05 Dec 2005 23:52:38 -0600 Message-ID: <4395273B.90902@tgharold.com> Date: Tue, 06 Dec 2005 00:52:59 -0500 From: Thomas Harold User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en, ja, zh-cn, zh-hk, zh-sg, zh-tw, ko, ko-kp, ko-kr MIME-Version: 1.0 Cc: pgsql-performance@postgresql.org Subject: Re: two disks - best way to use them? References: <00fb01c5f772$59471410$0200a8c0@dell8200> <6.2.5.6.0.20051202145746.01dc7b68@earthlink.net> <43946148.9010607@tgharold.com> <43946EA1.8090908@tgharold.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=1.189 required=5 tests=[AWL=-0.333, MISSING_HEADERS=0.189, RCVD_IN_BL_SPAMCOP_NET=1.332, UNPARSEABLE_RELAY=0.001] X-Spam-Score: 1.189 X-Spam-Level: * X-Archive-Number: 200512/143 X-Sequence-Number: 15964 David Lang wrote: > in that case you logicly have two disks, so see the post from Ron > earlier in this thread. And it's a very nice performance gain. Percent spent waiting according to "top" is down around 10-20% instead of 80-90%. While I'm not prepared to benchmark, database performance is way up. The client machines that are writing the data are running closer to 100% CPU (before they were well below 50% CPU utilization).