Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 1FDF42E3D50 for ; Fri, 30 Nov 2007 17:48:38 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 65241-07 for ; Fri, 30 Nov 2007 17:48:26 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 1D0422E3D4C for ; Fri, 30 Nov 2007 17:48:26 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lAULmOWc007342; Fri, 30 Nov 2007 16:48:24 -0500 (EST) To: "Jonah H. Harris" cc: "Campbell, Lance" , "posgres support" Subject: Re: Enhancement request In-reply-to: <36e682920711301332q1cce5db9qe44fb068fcd5608d@mail.gmail.com> References: <36e682920711301218m703b3c67s6f547fd7b9b60e7c@mail.gmail.com> <7099.1196458205@sss.pgh.pa.us> <36e682920711301332q1cce5db9qe44fb068fcd5608d@mail.gmail.com> Comments: In-reply-to "Jonah H. Harris" message dated "Fri, 30 Nov 2007 16:32:25 -0500" Date: Fri, 30 Nov 2007 16:48:24 -0500 Message-ID: <7341.1196459304@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/266 X-Sequence-Number: 27509 "Jonah H. Harris" writes: > On Nov 30, 2007 4:30 PM, Tom Lane wrote: >> AFAICS we are moving as fast as we can in the direction of auto vacuum >> and analyze. Adding more frammishes to the manual commands seems like >> gilding the buggy whip. > Autovacuum will never be the be all end all. No doubt, which is why no one has proposed removing the manual commands. (Yet, anyway.) But adding complication to them is not going to be an easy sale. We have limited manpower for development and we cannot afford to get bogged down maintaining a codebase with enormous bloat from useless legacy "features". So: show me a use case for this that will still make sense in a mostly-autovacuum world. I can see a need for manual vacuuming of individual special-case tables, but I don't see why schema-wide vacuuming is so useful as to justify diverting development effort to it. regards, tom lane