Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id E5E0E9FB22F for ; Wed, 17 Jan 2007 16:13:15 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 55396-10 for ; Wed, 17 Jan 2007 16:12:56 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from cronos.madness.at (madness.at [217.196.146.217]) by postgresql.org (Postfix) with ESMTP id DACB49FB228 for ; Wed, 17 Jan 2007 16:12:58 -0400 (AST) Received: from mastermind.kaltenbrunner.cc ([83.215.233.60]) by cronos.madness.at with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.62 (FreeBSD)) (envelope-from ) id 1H7H9I-0006AO-W0; Wed, 17 Jan 2007 21:12:55 +0100 Message-ID: <45AE833B.60407@kaltenbrunner.cc> Date: Wed, 17 Jan 2007 21:12:43 +0100 From: Stefan Kaltenbrunner User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Tom Lane CC: Bill Moran , Alvaro Herrera , pgsql-general@postgresql.org Subject: Re: Index bloat of 4x References: <20070117093223.bcdb302e.wmoran@collaborativefusion.com> <20070117154251.GG26080@alvh.no-ip.org> <20070117113216.a6d72185.wmoran@collaborativefusion.com> <24871.1169052974@sss.pgh.pa.us> In-Reply-To: <24871.1169052974@sss.pgh.pa.us> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/931 X-Sequence-Number: 107471 Tom Lane wrote: > Bill Moran writes: >> The entire database was around 28M prior to the upgrades, etc. Immediately >> after the upgrades, it was ~270M. Following a vacuum full, it dropped to >> 165M. Following a database-wide reindex, it dropped to 30M. > > As Alvaro said, vacuum full doesn't shrink indexes but in fact bloats them. > (Worst case, they could double in size, if the vacuum moves every row; > there's an intermediate state where there have to be index entries for > both old and new copies of each moved row, to ensure things are > consistent if the vacuum crashes right there.) > > So the above doesn't sound too unlikely. Perhaps we should recommend > vac full + reindex as standard cleanup procedure. Longer term, maybe > teach vac full to do an automatic reindex if it's moved more than X% of > the rows. Or forget the current vac full implementation entirely, and > go over to something acting more like CLUSTER ... we have to recommend the CLUSTER "way" to fix overly bloated databases quite often to people on IRC because vacuum full is unreasonably slow on highly fragmented databases. Doing something like that internally for vacuum full sounds like a reasonable idea except for the additional disk usage during the process which might cause issues for people ... Stefan