X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id E231A9DCDD9; Wed, 1 Feb 2006 13:29:10 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 94324-01; Wed, 1 Feb 2006 13:29:08 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from alvh.no-ip.org (201-220-123-99.bk10-dsl.surnet.cl [201.220.123.99]) by postgresql.org (Postfix) with ESMTP id E11FA9DCDCE; Wed, 1 Feb 2006 13:29:06 -0400 (AST) Received: by alvh.no-ip.org (Postfix, from userid 1000) id CB6BAC2DC59; Wed, 1 Feb 2006 14:29:05 -0300 (CLST) Date: Wed, 1 Feb 2006 14:29:05 -0300 From: Alvaro Herrera To: Chris Browne Cc: pgsql-admin@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] autovacuum Message-ID: <20060201172905.GA7879@surnet.cl> Mail-Followup-To: Chris Browne , pgsql-admin@postgresql.org, pgsql-hackers@postgresql.org References: <1137992841.28304.48.camel@localhost.localdomain> <5001.71.40.140.99.1138286468.squirrel@mail.tocr.com> <60psm7knlq.fsf@dba2.int.libertyrms.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60psm7knlq.fsf@dba2.int.libertyrms.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=2.661 required=5 tests=[AWL=-1.059, DNS_FROM_RFC_ABUSE=0.479, DNS_FROM_RFC_POST=1.44, RCVD_IN_DSBL=1.801] X-Spam-Score: 2.661 X-Spam-Level: ** X-Archive-Number: 200602/3 X-Sequence-Number: 20424 Chris Browne wrote: > It strikes me as a slick idea for autovacuum to take on that > behaviour. If the daily backup runs for 2h, then it is quite futile > to bother vacuuming a table multiple times during that 2h period when > none of the tuples obsoleted during the 2h period will be able to be > cleaned out until the end. Hmm, yeah, sounds useful. There's one implementation issue to notice however, and it's that the autovacuum process dies and restarts for each iteration, so there's no way for it to remember previous state unless it's saved somewhere permanent, as the stats info is. However this seems at least slightly redundant with the "maintenance window" feature -- you could set a high barrier to vacuum during the daily backup period instead. (Anybody up for doing this job?) -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "No single strategy is always right (Unless the boss says so)" (Larry Wall)