Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 278119FB34D for ; Sun, 6 May 2007 06:17:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 53373-08 for ; Sun, 6 May 2007 06:17:28 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by postgresql.org (Postfix) with ESMTP id 924E79FB33F for ; Sun, 6 May 2007 06:17:31 -0300 (ADT) Received: from trofast.ipv6.sesse.net ([2001:700:300:1803:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1Hkcrw-0000Af-En; Sun, 06 May 2007 11:17:28 +0200 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1Hkcrc-0005sA-00; Sun, 06 May 2007 11:17:08 +0200 Date: Sun, 6 May 2007 11:17:07 +0200 From: "Steinar H. Gunderson" To: Yudhvir Singh Sidhu Cc: pgsql-performance@postgresql.org Subject: Re: How to Find Cause of Long Vacuum Times - NOOB Question Message-ID: <20070506091707.GB22451@uio.no> Mail-Followup-To: Yudhvir Singh Sidhu , pgsql-performance@postgresql.org References: <463D0BD5.3010404@gmail.com> <20070505234014.GA15522@uio.no> <463D5F28.5060006@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <463D5F28.5060006@gmail.com> X-Operating-System: Linux 2.6.20.4 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/63 X-Sequence-Number: 24453 On Sat, May 05, 2007 at 09:52:56PM -0700, Yudhvir Singh Sidhu wrote: > Here is what I think the story is: > a. Large amounts of rows are added to and deleted from a table - daily. > With this much activity, the statistics get out of whack easily. That's > where ANALYZE or VACUUM ANALYZE would help with query speed. You are still confusing ANALYZE and VACUUM. Those are distinct operations, and help for different reasons. Deleting rows leaves "dead rows" -- for various reasons, Postgres can't actually remove them from disk at the DELETE point. VACUUM scans through the disk, searching for dead rows, and actually marks them as removed. This results in faster query times since there will be less data overall to search for. ANALYZE updates the statistics, as mentioned. Yes, by adding or deleting a lot of data, the estimates can get out of whack, leading to bad query plans. > b. If ANALYZE does not have a direct impact on vacuum times, what does? > Meaning what in this EXPLAIN/ANALYZE and Indexing world would have a > direct impact? Improving your vacuum speed is overall not that easy (although there are options you can tweak, and you can of course improve your hardware). The simplest thing to do is simply to vacuum more often, as there will be less work to do each time. It's a bit like cleaning your house -- it might be less work to clean it once a year, but it sure is a better idea in the long run to clean a bit every now and then. :-) /* Steinar */ -- Homepage: http://www.sesse.net/