X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 7A96D3A4362 for ; Wed, 3 Nov 2004 12:01:12 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 16279-10 for ; Wed, 3 Nov 2004 12:01:00 +0000 (GMT) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by svr1.postgresql.org (Postfix) with SMTP id E9BF53A42E2 for ; Wed, 3 Nov 2004 12:01:02 +0000 (GMT) Received: from unknown (HELO phlogiston.dydns.org) (a.sullivan@rogers.com@65.49.125.184 with login) by smtp103.rog.mail.re2.yahoo.com with SMTP; 3 Nov 2004 12:01:01 -0000 Received: by phlogiston.dydns.org (Postfix, from userid 1000) id 0A0B44048; Wed, 3 Nov 2004 07:01:00 -0500 (EST) Date: Wed, 3 Nov 2004 07:01:00 -0500 From: Andrew Sullivan To: pgsql-sql@postgresql.org Subject: Re: vacuum analyze slows sql query Message-ID: <20041103120059.GA14880@phlogiston.dyndns.org> Mail-Followup-To: pgsql-sql@postgresql.org References: <20041103025031.43795.qmail@web52103.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041103025031.43795.qmail@web52103.mail.yahoo.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200411/24 X-Sequence-Number: 19343 On Tue, Nov 02, 2004 at 06:50:31PM -0800, patrick ~ wrote: > We have a nightly "garbage collection" process that runs and purges > any old data. After this process a 'vacuum analyze' is kicked off > (regardless of whether or not any data was actually purged). > > At this point I should mention that our customer sites are running > PostgreSQL 7.1.3; however, I am able to reproduce the issue on 7.4.2. A 7.1 system takes an exclusive lock on any VACUUM. It's the same as VACUUM FULL in 7.4. Nothing you can do to make that not be sluggish. You want to get those sites off 7.1 anyway. At the very least, you should be aware of xid exhaustion which can be prevented in 7.1 only with an initdb and complete restore. Failure to accommodate that will mean that one day your databases will just disappear. Current VACUUM certainly does impose a serious I/O load; this is the reason for the vacuum setting tweaks in 8.0. See the -hackers archives (from more than a year ago now) for (for instance) Jan Wieck's discussion of his feature and the subsequent debates. > I noticed that a freshly created db with freshly inserted data (from > a previous pg_dump) would result in quite fast results. However, > after running 'vacuum analyze' the very same query slowed down about > 1250x (Time: 1080688.921 ms vs Time: 864.522 ms). > My best guess is that there's something going on inside your function. I'd be looking for locks here, though. That makes no sense, given that you've only 78 rows being returned. BTW, this topic should probably be better pursued on -performance. A -- Andrew Sullivan | ajs@crankycanuck.ca I remember when computers were frustrating because they *did* exactly what you told them to. That actually seems sort of quaint now. --J.D. Baldwin