Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id ECCBC9F9F71 for ; Tue, 4 Sep 2007 14:49:17 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 46087-08 for ; Tue, 4 Sep 2007 14:49:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from outbound-mail-61.bluehost.com (outbound-mail-61.bluehost.com [69.89.21.21]) by postgresql.org (Postfix) with SMTP id 57E2F9F9F68 for ; Tue, 4 Sep 2007 14:49:13 -0300 (ADT) Received: (qmail 5554 invoked by uid 0); 4 Sep 2007 17:49:11 -0000 Received: from unknown (HELO box54.bluehost.com) (69.89.20.54) by mailproxy4.bluehost.com with SMTP; 4 Sep 2007 17:49:11 -0000 Received: from corp.messageone.com ([66.219.55.2] helo=janetvito.austin.messageone.com) by box54.bluehost.com with esmtp (Exim 4.66) (envelope-from ) id 1IScWQ-00018K-HN for pgsql-performance@postgresql.org; Tue, 04 Sep 2007 11:49:10 -0600 From: Kevin Kempter To: pgsql-performance@postgresql.org Subject: Re: Vacum Analyze problem Date: Tue, 4 Sep 2007 11:45:21 -0600 User-Agent: KMail/1.9.7 References: <1275.192.168.1.229.1188926827.squirrel@webmail.akyasociados.com.ar> In-Reply-To: <1275.192.168.1.229.1188926827.squirrel@webmail.akyasociados.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709041145.21363.kevin@kevinkempterllc.com> X-Identified-User: {840:box54.bluehost.com:kevinkem:kevinkempterllc.com} {sentby:bopbeforesmtp 66.219.55.2 authed with kevinkempterllc.com} X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/22 X-Sequence-Number: 26567 On Tuesday 04 September 2007 11:27:07 rafael@akyasociados.com.ar wrote: > Hello everyone: > > I wanted to ask you about how the VACUUM ANALYZE works. is it possible > that something can happen in order to reset its effects forcing to execute > the VACUUM ANALYZE comand again? i am asking this because i am struggling > with a query which works ok after i run a VACUUM ANALYZE, however, > sudennly, it starts to take forever (the execution of the query) until i > make another VACUUM ANALYZE, and so on ... > I'd like to point that i am a novice when it comes to non basic > postgresql performance related stuff. > > Thank you all in advance > > Rafael > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly Rafael; Vacuum Analyze performs 2 tasks at once. 1) Vacuum - this analyzes the table pages and sets appropriate dead row space (those from old updates or deletes that are not possibly needed by any existing transactions) as such that the db can re-use (over-write) that space. 2) Analyze - Like an Oracle compute stats, updates the system catalogs with current table stat data. The Vacuum will improve queries since the dead space can be re-used and any dead space if the table you are having issues with is a high volume table then the solution is generally to run vacuum more often - I've seen tables that needed a vacuum every 5 minutes due to significant sustained churn. The Analyze of course is key for the planner, if the table is growing rapidly then running analyze more often will help, if however there is lots of churn but little change in the data (i.e. lots of inserts followed by delete's of the same rows) then a straight vacuum is probably what you need. If the data is changing rapidly then bumping up the default_statistics_target value may help - you can bump the default_statistics_target for a single table in the pg_autovacuum system catalog table. Hope this helps... /Kevin