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 42398D8917 for ; Thu, 1 Sep 2005 19:01:58 -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 37957-02 for ; Thu, 1 Sep 2005 22:01:56 +0000 (GMT) Received: from newman.lshift.net (host226.lshift.net [195.172.218.226]) by svr1.postgresql.org (Postfix) with ESMTP id EF9C0D8915 for ; Thu, 1 Sep 2005 19:01:55 -0300 (ADT) Received: (qmail 16724 invoked by uid 1004); 1 Sep 2005 22:01:58 -0000 Received: from 10.224.189.77 by newman (envelope-from , uid 64011) with qmail-scanner-1.24 (clamdscan: 0.80/627. Clear:RC:1(10.224.189.77):. Processed in 0.013894 secs); 01 Sep 2005 22:01:58 -0000 Received: from ponder.lshift.net (HELO localhost) ([10.224.189.77]) (envelope-sender ) by newman.lshift.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 1 Sep 2005 22:01:58 -0000 Date: Thu, 1 Sep 2005 23:01:58 +0100 From: Matthew Sackman To: pgsql-performance@postgresql.org Subject: Re: Massive performance issues Message-ID: <20050901220158.GF7131@pongo.lshift.net> Mail-Followup-To: pgsql-performance@postgresql.org References: <20050901174231.GE23970@pongo.lshift.net> <43176A95.70506@tweakers.net> <20050901211359.GD7131@pongo.lshift.net> <20050901215245.GA4242@uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050901215245.GA4242@uio.no> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.272 required=5 tests=[AWL=-0.102, DNS_FROM_RFC_ABUSE=0.374] X-Spam-Level: X-Archive-Number: 200509/32 X-Sequence-Number: 14340 On Thu, Sep 01, 2005 at 11:52:45PM +0200, Steinar H. Gunderson wrote: > On Thu, Sep 01, 2005 at 10:13:59PM +0100, Matthew Sackman wrote: > > Well that's the thing - on the queries where it decides to use the index > > it only reads at around 3MB/s and the CPU is maxed out, whereas when it > > doesn't use the index, the disk is being read at 60MB/s. So when it > > decides to use an index, I don't seem to be IO bound at all. Or at least > > that's the way it seems to me. > > You are I/O bound; your disk is doing lots and lots of seeks. The SATA > interface is not the bottleneck; the disk's ability to rotate and move its > heads is. Ahh of course (/me hits head against wall). Because I've /seen/ it read at 60MB/s I was assuming that if it wasn't reading that fast then I'm not IO bound but of course, it's not reading sequentially. That all makes sense. Been a long day etc... ;-) Matthew