Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id E9A642E3143 for ; Wed, 5 Dec 2007 10:09:45 -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 02463-06 for ; Wed, 5 Dec 2007 10:09:40 -0400 (AST) Received: from tinlc.com (unknown [72.18.206.65]) by postgresql.org (Postfix) with ESMTP id E25422E01D6 for ; Wed, 5 Dec 2007 10:09:40 -0400 (AST) Received: from localhost ([127.0.0.1]) by tinlc.com with smtp (Exim 4.60) (envelope-from ) id 1IzuxN-0000IK-9f; Wed, 05 Dec 2007 09:10:33 -0500 From: "Greg Sabino Mullane" To: pgsql-admin@postgresql.org Subject: Re: Enhancement request X-PGP-Key: 2529 DF6A B8F7 9407 E944 45B4 BC9B 9067 1496 4AC8 X-Request-PGP: http://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 In-Reply-To: <10684.1196480658@sss.pgh.pa.us> Date: Wed, 5 Dec 2007 14:10:33 -0000 X-Mailer: JoyMail 2.01 Message-ID: <09fbbcab762fc5279e45349ce1cbad93@biglumber.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/19 X-Sequence-Number: 27536 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Tom Lane wrote: > Certainly it isn't a mostly-autovacuum world in 8.2 or earlier releases, > but that's irrelevant to whether it makes sense to expend effort on a > feature that would appear (at the earliest) in 8.4. Autovac in 8.3 is > very significantly ahead of where it was in 8.2 --- to the point that > we've turned it on by default --- and I predict that the pressure of > being on by default will really light the afterburners behind its > development. I think it's entirely likely that by the time 8.4 is > ready, it will be perfectly fair to characterize manual vacuuming > as a buggy-whip technology, at least for all but the > three-sigmas-above-normal users. I think this is being extremely over-optimistic. 8.4 is now the next release. Autovacuum still has a long ways to go, and it's still fairly useless out of the box for large relations. I also truly cannot imagine that 8.4 is going to magically solve the vacuum-later vs. performance-now issue. > And I'd *much* rather see development effort going into making that > vision come true, than into adding questionably-useful complexity in > the support for manual vacuuming. It doesn't sound questionable, it sounds like a real-world feature request from someone who would immediately benefit from it. Also, development is not a zero-sum game - someone writing this patch would not necessarily have the skills (or time, or interest) in improving auto-vacuum. I am curious however, as to what the future vision of autovacuum is. Will it be so efficient that it won't impact all but the busiest tables? Will it be able to figure out the best time to vacuum on its own? Will it stop itself mid-run if the need arises? - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200712050906 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFHVrEMvJuQZxSWSsgRAwK7AKDUv5mV74knvupqfshb77CruKsZLQCfTDD8 w/36OiC7XRu+3kqHP3vi8Og= =pcpb -----END PGP SIGNATURE-----