Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 4A58D6501DC for ; Wed, 26 Nov 2008 17:04:14 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 57701-05 for ; Wed, 26 Nov 2008 17:04:11 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mail.postgresql.org (Postfix) with ESMTP id 0F7846503BA for ; Wed, 26 Nov 2008 17:04:09 -0400 (AST) Received: by rv-out-0506.google.com with SMTP id b25so605583rvf.43 for ; Wed, 26 Nov 2008 13:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=jVXtJSKsrNAvdMSbXYr9RI72RVSZH2sJCInAm2eixYg=; b=i0fPSvcxs2wu69GxH9ZSUxJbXcNhyc7IcmHE9PiOp2BacB8CKTuIUfRGwovwWdJ9oF O/Hql5LZDryTJ15uEGwdFUUgDHijzT5CiiDtthJhRh4tzfKmcSs8ZZschLf79JTOJ37U LIDtW/QRAR3GEiiAMQFcb7kVrd+mXIyHTCB3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fguUJu7Nypy7HxgkrlbbkncqxfcJ8MoFocbHitAtH6vSQ/2DN7AFnXLLeS+5/dHMtG 9DjW9i58Nc4G/Xl+4m26UpJMkKCpw6IJPIIWR6O5XXwhd0CadA64SKl+LGLlUYIrQYpA P3Y+LjdewEXJjafnY17JogsTmezxXml01eih8= Received: by 10.115.79.8 with SMTP id g8mr3596686wal.65.1227733448434; Wed, 26 Nov 2008 13:04:08 -0800 (PST) Received: by 10.114.190.12 with HTTP; Wed, 26 Nov 2008 13:04:08 -0800 (PST) Message-ID: Date: Wed, 26 Nov 2008 14:04:08 -0700 From: "Scott Marlowe" To: "Matthew T. O'Connor" Subject: Re: Vacuum Problems Cc: "Rafael Domiciano" , "Rafael Martinez" , "pgsql-admin@postgresql.org" In-Reply-To: <492DA95D.3010303@zeut.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a0028490811260543x74d02719w775a457999cfc74@mail.gmail.com> <492D5C87.5090505@usit.uio.no> <3a0028490811260700w6e8d9d86o24effbe0bea2bddb@mail.gmail.com> <3a0028490811260921l5d6aac06v54dca32aae672b97@mail.gmail.com> <492DA95D.3010303@zeut.net> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200811/157 X-Sequence-Number: 30811 On Wed, Nov 26, 2008 at 12:54 PM, Matthew T. O'Connor wrote: > Rafael Domiciano wrote: >> >> I'm not using autovacuum. Regular vacuum goes ok. >> To see the last 10 lines of verbose i will need to run vacuum tonight >> >> If a run a reindex before the vacuum full, increase the "speed" of doing >> vacuum? I found something about it googling. > > It might help a bit, but by the end of VACUUM FULL you would need to run > reindex again as VACUUM FULL tends to cause a lot of index bloat. It is > normal for tables to have some slack space, so if you do a regular vacuum > every day (or let autovacuum) it's normal for the table to be a bit bigger > than after a VACUUM FULL, but they should ready steady state and stop > growing. But there are certain use cases that would be classified as pathological in nature, that you can't handle with regular vacuum. It's only when you've proven that that's your case, and you can't program around it, that you should start using vacuum full though. vacuum full is so expensive in terms of time the system is largely unusable combined with the need to run reindex or replace the whole thing with cluster, that if regular or autovacuum can handle the load, then that's what you do. I've only seen cases where things like large imports were using a shared table where it would get bloated insanely if three or four imports were running at the same time with the occasional update with no where clause. Since you can't truncate the table, because it's shared with other imports, you have to vacuum it, but if you bloat it by 10x or 100x normal size in 30 seconds, no amount of regular vacuuming will help. So, users need to understand why they're always asked if they're running autovacuum or not. It's like asking someone with a nonfunctioning dryer if they've cleaned the lint trap. It's just something we assume someone should try first unless there's a good reason not to. Because it does work so well most of the time. I run autovacuum. I also email myself the output from vacuum verbose every week, to look through and see how the tables are looking. A quick look near the end tells you if you're mostly ok, and quick investigation can find bloated tables pretty fast. So, for the OP, have you tried autovacuum, and why aren't you using it. Most of the time people aren't running it it's for erroneous reasons. Also, look into updating to 8.3 or above. With its HOT update mechanism, and autovacuum enabled by default it handles these situations quite easily.