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 A16529DCBB0 for ; Thu, 22 Dec 2005 00:01:20 -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 94720-09 for ; Thu, 22 Dec 2005 00:01:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 53A0E9DCBE3 for ; Thu, 22 Dec 2005 00:01:17 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 7616631F57; Thu, 22 Dec 2005 05:01:16 +0100 (MET) From: Qingqing Zhou X-Newsgroups: pgsql.performance Subject: Re: CPU and RAM Date: Wed, 21 Dec 2005 23:01:12 -0500 Organization: Hub.Org Networking Services Lines: 20 Message-ID: References: <45b42ce40512211720t164ea389wa5bfd0cbae6c80e2@mail.gmail.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Complaints-To: usenet@news.hub.org To: Harry Jackson X-X-Sender: zhouqq@eon.cs In-Reply-To: <45b42ce40512211720t164ea389wa5bfd0cbae6c80e2@mail.gmail.com> To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.138 required=5 tests=[AWL=0.138] X-Spam-Score: 0.138 X-Spam-Level: X-Archive-Number: 200512/559 X-Sequence-Number: 16380 On Thu, 22 Dec 2005, Harry Jackson wrote: > I am currently using a dual Opteron (248) single core system (RAM > PC3200) and for a change I am finding that the bottleneck is not disk > I/O but CPU/RAM (not sure which). The reason for this is that the most > frequently accessed tables/indexes are all held in RAM and when > querying the database there is almost no disk activity which is great, > most of the time. > > At the moment everything is working OK but I am noticing an almost > linear increase in time to retrieve data from the database as the data > set increases in size. Clustering knocks the access times down by 25% Let's find out what's going on first. Can you find out the most expensive query. Also, according to you what you said: (1) execution time is linear to data set size (2) no disk IO - so why cluster will improve 25%? Regards, Qingqing