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 8C4DC9DC84B for ; Wed, 1 Feb 2006 23:06:04 -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 80765-05 for ; Wed, 1 Feb 2006 23:06:08 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by postgresql.org (Postfix) with ESMTP id 335F29DC807 for ; Wed, 1 Feb 2006 23:06:02 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.13.1/8.13.1) with ESMTP id k1235xx1065069 for ; Thu, 2 Feb 2006 03:05:59 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.13.1/8.13.1/Submit) id k122c0N1020530 for pgsql-admin@postgresql.org; Wed, 1 Feb 2006 22:38:00 -0400 (AST) (envelope-from news) From: Christopher Browne X-Newsgroups: pgsql.admin Subject: Re: autovacuum Date: Wed, 01 Feb 2006 18:32:31 -0800 Organization: cbbrowne Computing Inc Lines: 35 Message-ID: References: <1137992841.28304.48.camel@localhost.localdomain> <5001.71.40.140.99.1138286468.squirrel@mail.tocr.com> <60bqxqls6m.fsf@dba2.int.libertyrms.com> <20060201212116.GN95850@pervasive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org X-message-flag: Outlook is rather hackable, isn't it? X-Home-Page: http://www.cbbrowne.com/info/ X-Affero: http://svcs.affero.net/rm.php?r=cbbrowne User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) Cancel-Lock: sha1:mCc/ilhAxoyZG5kKwd3M6LgO5BI= To: pgsql-admin@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=-1.276 required=5 tests=[ALL_TRUSTED=-1.44, AWL=0.164] X-Spam-Score: -1.276 X-Spam-Level: X-Archive-Number: 200602/11 X-Sequence-Number: 20432 > This seems maybe a bit overkill to me. I think what would be more useful > is if autovacuum could execute more than one vacuum at a time, and you > could specify tables that are high priority (or possibly just say that > all tables with less than X live tuples in them are high priority). That > way a longer-running vacuum on a large table wouldn't prevent more > vacuum-sensative tables (such as queues) from being vacuumed frequently > enough. Actually, I can think of a case for much the opposite, namely to want to concurrently vacuum some LARGE tables... Suppose you have 2 rather big tables that get updates on similar schedules such that both will have a lot of dead tuples at similar times. And suppose both of these tables are Way Large, so that they take six hours to vacuum. I could argue for kicking off vacuums on both, at the same moment; they'll both be occupying transactions for 1/4 of a day, and, with possibly related patterns of updates, doing them one after the other *wouldn't* forcibly get you more tuples cleaned than doing them concurrently. I'm not sure that's a case to push for, either, as something pg_autovacuum is smart enough to handle; I'm just putting out some ideas that got enough internal discussion to suggest they were interesting enough to let others consider... -- "cbbrowne","@","gmail.com" http://cbbrowne.com/info/linuxdistributions.html "Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete strangers to kill again." -- Unknown, Marin County newspaper's TV listing for _The Wizard of Oz_