Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 2CFF465054D for ; Tue, 15 Jul 2008 12:13:00 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 56897-08 for ; Tue, 15 Jul 2008 12:12:04 -0300 (ADT) Received: from mx1.hub.org (mx1.hub.org [200.46.208.106]) by postgresql.org (Postfix) with ESMTP id 45286650084 for ; Tue, 15 Jul 2008 12:12:11 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by mx1.hub.org (Postfix) with ESMTP id AC817B079DB for ; Tue, 15 Jul 2008 12:12:04 -0300 (ADT) Received: from relay2.r2.iad.emailsrvr.com (localhost [127.0.0.1]) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id CA7DB44C312; Tue, 15 Jul 2008 11:12:06 -0400 (EDT) Received: by relay2.r2.iad.emailsrvr.com (Authenticated sender: matthew-AT-zeut.net) with ESMTP id ACEE744C33A; Tue, 15 Jul 2008 11:12:06 -0400 (EDT) Message-ID: <487CBE5E.6030903@zeut.net> Date: Tue, 15 Jul 2008 11:12:30 -0400 From: "Matthew T. O'Connor" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Chris Hoover CC: "pgsql-admin@postgresql.org Admin" Subject: Re: More Autovacuum questions References: <1d219a6f0807150619o567709ebu7d28429d2907bf82@mail.gmail.com> In-Reply-To: <1d219a6f0807150619o567709ebu7d28429d2907bf82@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200807/133 X-Sequence-Number: 29743 Chris Hoover wrote: > Another question. > > When autovacuum sleeps, does it release the lock it has on the table? > > What we would like to have happen is for vacuum to work for a while, > sleep, and while it is sleeping run an analyze on the table. We need > this due to how quickly our data is changing. Currently we are running > analyze every 5 minutes against the table of question and get a very > serious performance hit when vacuum runs due to the index stats getting > out of date. As soon as we rerun analyze after the vacuum happiness > returns. > > The pg_total_relation_size for the table in question is 64GB, and as > stated above is a very heavily used and modifed table. As Alvaro already said this is a case where autovacuum still isn't great. Perhaps what you should do here is disable auto-vacumming of the table during busy periods and and only have it vacuum at off peak times?