X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id EF345D9E78; Wed, 5 Oct 2005 07:33:13 -0300 (ADT) 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 33240-03; Wed, 5 Oct 2005 10:33:06 +0000 (GMT) Received: from mail.skype.net (mail.skype.net [195.215.8.149]) by svr1.postgresql.org (Postfix) with ESMTP id 95AEFD9072; Wed, 5 Oct 2005 07:33:06 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 784464DD89; Wed, 5 Oct 2005 12:33:08 +0200 (CEST) Received: from [192.168.0.41] (joltid-gw.joltid.org [195.50.194.24]) by mail.skype.net (Postfix) with ESMTP id 0A1594DE60; Wed, 5 Oct 2005 12:32:53 +0200 (CEST) Subject: Re: [PERFORM] A Better External Sort? From: Hannu Krosing To: Michael Stone Cc: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org In-Reply-To: <20051005094315.GX2241@mathom.us> References: <31833713.1128111650174.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> <200510031334.02030.josh@agliodbs.com> <1128372151.28509.1.camel@toonses.gghcwest.com> <200510031416.15620.josh@agliodbs.com> <1128375790.5882.18.camel@fuji.krosing.net> <20051005094315.GX2241@mathom.us> Content-Type: text/plain Date: Wed, 05 Oct 2005 13:32:52 +0300 Message-Id: <1128508373.8561.28.camel@fuji.krosing.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.008 required=5 tests=[AWL=0.008] X-Spam-Level: X-Archive-Number: 200510/206 X-Sequence-Number: 74065 On K, 2005-10-05 at 05:43 -0400, Michael Stone wrote: > On Tue, Oct 04, 2005 at 12:43:10AM +0300, Hannu Krosing wrote: > >Just FYI, I run a count(*) on a 15.6GB table on a lightly loaded db and > >it run in 163 sec. (Dual opteron 2.6GHz, 6GB RAM, 6 x 74GB 15k disks in > >RAID10, reiserfs). A little less than 100MB sec. > > And none of that 15G table is in the 6G RAM? I believe so, as there had been another query running for some time, doing a select form a 50GB table. -- Hannu Krosing