Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id C8DD79F9D92 for ; Sun, 23 Sep 2007 17:58:12 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 43718-01 for ; Sun, 23 Sep 2007 17:58:02 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from lists.commandprompt.com (host-254.commandprompt.net [207.173.203.254]) by postgresql.org (Postfix) with ESMTP id 4F7669F9B57 for ; Sun, 23 Sep 2007 17:58:06 -0300 (ADT) Received: from perhan.alvh.no-ip.org ([190.95.8.15]) (authenticated bits=0) by lists.commandprompt.com (8.13.7/8.13.6) with ESMTP id l8NKw237007199; Sun, 23 Sep 2007 13:58:03 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5BF2247C41; Sun, 23 Sep 2007 16:57:59 -0400 (CLT) Date: Sun, 23 Sep 2007 16:57:59 -0400 From: Alvaro Herrera To: Carlos Moreno Cc: pgsql-performance@postgresql.org Subject: Re: Possible explanations for catastrophic performance deterioration? Message-ID: <20070923205759.GD5679@alvh.no-ip.org> References: <46F6981B.1010600@mochima.com> <36e682920709230956p1312745eif1c6ba7a342dae3d@mail.gmail.com> <46F6AD2D.4090300@mochima.com> <20070923182349.GC5679@alvh.no-ip.org> <46F6BA82.3080101@mochima.com> <36e682920709231224y3fb13ce3t9dd4217215c62bf7@mail.gmail.com> <46F6CD9A.2090600@mochima.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F6CD9A.2090600@mochima.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on projects.commandprompt.com X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (lists.commandprompt.com [192.168.2.159]); Sun, 23 Sep 2007 13:58:03 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/407 X-Sequence-Number: 26952 Carlos Moreno wrote: > That is: the first time I run the query, it has to go through the > disk; in the normal case it would have to read 100MB of data, but due > to bloating, it actually has to go through 2GB of data. Ok, but > then, it will load only 100MB (the ones that are not "uncollected > disk garbage") to memory. The next time that I run the query, the > server would only need to read 100MB from memory --- the result should > be instantaneous... Wrong. If there is 2GB of data, 1900MB of which is dead tuples, those pages would still have to be scanned for the count(*). The system does not distinguish "pages which have no live tuples" from other pages, so it has to load them all. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "[PostgreSQL] is a great group; in my opinion it is THE best open source development communities in existence anywhere." (Lamar Owen)