Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id DE58D9FBA45 for ; Tue, 13 Mar 2007 19:20:45 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 97835-03 for ; Tue, 13 Mar 2007 19:20:42 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by postgresql.org (Postfix) with ESMTP id B74FE9FB3BA for ; Tue, 13 Mar 2007 19:20:42 -0300 (ADT) Received: by wr-out-0506.google.com with SMTP id 71so2680053wri for ; Tue, 13 Mar 2007 15:20:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=T0gs8xYIOmM6q9AwweIUE1r2Eb/3TqOSnj2f0cZjR0NHSYiYX0dRFJ9QTfPWYt9i0A/rtRFFr4/C88Q/2AwaTGXGzND/jXvZiCx4Wr3VLWELgApt1ag8FglFPPeglDu/mX7olSwooNwLLRC8jeoeTPoX8vwIyi92xNY76gELn2k= 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=a5rzV1dVsLAADhaWNk87WCWs4O4pbRvRRmowFRSt19oWsjnh/xde5XLv6i/DayZCDlBy9JDpVtnBIma9q87BDw90aPNdkmj8K2FRW7fi3LM+BO05tsDF9qj2Is+nvTFXAR3C+wUIQZU7/vfodAbtHxR1ogflWPZAiBF3H1gSt/M= Received: by 10.114.110.1 with SMTP id i1mr2627256wac.1173824438135; Tue, 13 Mar 2007 15:20:38 -0700 (PDT) Received: by 10.114.158.16 with HTTP; Tue, 13 Mar 2007 15:20:38 -0700 (PDT) Message-ID: <92d3a4950703131520x27de4cc2w4780d0700cf606e2@mail.gmail.com> Date: Tue, 13 Mar 2007 23:20:38 +0100 From: "Anton Melser" To: "Heikki Linnakangas" Subject: Re: PostgreSQL 8.2.3 VACUUM Timings/Performance Cc: "Bruce McAlister" , pgsql-performance@postgresql.org In-Reply-To: <45EC2CCF.8020906@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45EC1931.3020701@enterprisedb.com> <45EC2CCF.8020906@enterprisedb.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200703/238 X-Sequence-Number: 23643 > In fact, getting rid of vacuum full, or changing it to work like > cluster, has been proposed in the past. The use case really is pretty > narrow; cluster is a lot faster if there's a lot of unused space in the > table, and if there's not, vacuum full isn't going to do much so there's > not much point running it in the first place. The reason it exists is > largely historical, there hasn't been a pressing reason to remove it either. I can assure you it is a great way to get back gigabytes when someone has put no vacuum strategy in place and your 200K row table (with about 200 bytes per row) is taking up 1.7gig!!! Vive le truncate table, and vive le vacuum full! :-) Anton