Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 1A0659F9EF9 for ; Wed, 12 Sep 2007 16:07:06 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 88507-07 for ; Wed, 12 Sep 2007 16:07:02 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by postgresql.org (Postfix) with ESMTP id D280F9FA060 for ; Wed, 12 Sep 2007 16:07:02 -0300 (ADT) Received: by ug-out-1314.google.com with SMTP id j3so308086ugf for ; Wed, 12 Sep 2007 12:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fR2rzLoojAALiTEcOqoo6jftOlVyx3tTXjhWixmXksU=; b=j7EwXl9DjFC+ZZKtI47ToHfzk07uPRqBN1Oc0LgVevRRPQHw9BkOCefm9vMvp84LjtMLpGdRw6SIOjy4mZxOf3kb3SJMXpuKdwZnkPrlb+Sxc38NE+5DVDUFKmnYW/BuNKMN8TJ/LSfLjTPfYXtSLCvrVjv3PCVbA5zYKuRAF7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ntTFeQUhCk+mlYNpdhDaKbW75uKNHkfuVgPMKB0NKbSjBxwTajBU4cbVmaYA85zMK0hneysQsTpD7/WudJUuSZ0kWLPzJHNeMf/bfU7NHwlCvCzkJpf7k13Oc3XILGs+V4GofW8t64orXYqTXVBkhckRAcyJbLcEuMIAtZXb3rk= Received: by 10.67.22.2 with SMTP id z2mr2160865ugi.1189624021543; Wed, 12 Sep 2007 12:07:01 -0700 (PDT) Received: by 10.66.220.7 with HTTP; Wed, 12 Sep 2007 12:07:01 -0700 (PDT) Message-ID: Date: Wed, 12 Sep 2007 14:07:01 -0500 From: "Scott Marlowe" To: "Mikko Partio" Subject: Re: [Again] Postgres performance problem Cc: "ruben@rentalia.com" , Decibel! , db@zigo.dhs.org, pgsql-performance@postgresql.org In-Reply-To: <2ca799770709121156l7ddbb20agf8086e8bfcbc881a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E636CB.8080008@rentalia.com> <43393.192.121.104.48.1189495883.squirrel@zigo.dhs.org> <46E64891.9080005@rentalia.com> <20070911225242.GG38801@decibel.org> <46E79865.906@rentalia.com> <2ca799770709121156l7ddbb20agf8086e8bfcbc881a@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/229 X-Sequence-Number: 26774 On 9/12/07, Mikko Partio wrote: > > > On 9/12/07, Scott Marlowe wrote: > > On 9/12/07, ruben@rentalia.com wrote: > > > > > Try a REINDEX. VACUUM FULL is especially hard on the indexes, and it's > > > > easy for them to seriously bloat. > > > > > > Reindex is done everyday after VACUUM FULL VERBOSE ANALYZE. I save also > > > the output averyday and save it into a log, and I can check that it is > > > done properly. > > > > Then you're vacuum full is wasted. A reindex accomplishes the same > > thing, plus shrinks indexes (vacuum full can bloat indexes). > > Aren't you mixing up REINDEX and CLUSTER? I don't think so. reindex (which runs on tables and indexes, so the name is a bit confusing, I admit) basically was originally a "repair" operation that rewrote the whole relation and wasn't completely transaction safe (way back, 7.2 days or so I think). Due to the issues with vacuum full bloating indexes, and being slowly replaced by regular vacuum, reindex received some attention to make it transaction / crash safe and has kind of take the place of vacuum full in terms of "how to fix bloated objects". cluster, otoh, rewrites the table into index order. Either one does what a vacuum full did / does, but generally does it better.