Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 21E40632693 for ; Thu, 11 Feb 2010 09:22:52 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 28037-08; Thu, 11 Feb 2010 13:22:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail137130.authsmtp.co.uk (outmail137130.authsmtp.co.uk [62.13.137.130]) by mail.postgresql.org (Postfix) with ESMTP id 04B3E633222; Thu, 11 Feb 2010 09:22:40 -0400 (AST) Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id o1BDMZ9u044145; Thu, 11 Feb 2010 13:22:35 GMT Received: from [10.0.1.26] (74-92-138-153-WashingtonDC.hfc.comcastbusiness.net [74.92.138.153]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id o1BDMS5l038104; Thu, 11 Feb 2010 13:22:29 GMT Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while From: Simon Riggs To: Heikki Linnakangas Cc: Andres Freund , pgsql-hackers@postgresql.org, Tom Lane In-Reply-To: <4B73FDC8.3050208@enterprisedb.com> References: <20100208043355.412637541B9@cvs.postgresql.org> <1265883032.7341.1149.camel@ebony> <201002111204.10183.andres@anarazel.de> <4B73FDC8.3050208@enterprisedb.com> Content-Type: text/plain Date: Thu, 11 Feb 2010 13:22:28 +0000 Message-Id: <1265894548.7341.1521.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Server-Quench: 8137c4ee-1710-11df-97bb-002264978518 X-Report-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksachtFaQRba1xT HGQLWlREUV57W2F/ aQMfagFDa0hQXgZi TklMQU1XHAJ3AVJe B2xqL3p3KwVFcH9w YQhqWnZbEkx7dkEu RhsBCGwBZGd9aWFL Bl1RcFEGbQNKfB1D bll4XHYMaStlM3Bw LC8aFBMcBw5qYB5Y EEk+BnU3ZGc3IhMG fCVKBTo0BElXDx8+ Khs4JxYbGEpUKVkj NVZpZ3szDiI3QiNj O2UvSG9GJ1gKR2I0 BBgSXkgZDzsVTyBG ShRgJh5UHjhfEjVY BU9IIwAA X-Authentic-SMTP: 61633235383639.1014:706/Kp X-AuthFastPath: 255 X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=AWL=0.000, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/849 X-Sequence-Number: 157192 On Thu, 2010-02-11 at 14:53 +0200, Heikki Linnakangas wrote: > Andres Freund wrote: > > On Thursday 11 February 2010 11:10:32 Simon Riggs wrote: > >> We should remove the moved in/off flag bits and make it a part of the > >> upgrade process to ensure the absence of those states. > > Essentially requiring a successfull VACUUM FULL or CLUSTER on all tables is > > imho in the same ballpark as requiring a dump+restore timewise on bigger > > databases. > > A plain VACUUM would be enough. Yes > But FWIW, +1 from me for keeping the support for HEAP_IN/OUT in 9.0. > It's not a lot of code, and that way we don't need to invent some > safeguards in pg_migrator to check that there's no HEAP_IN/OUT flags > just yet. The amount of code has nothing to do with keeping it or removing it. Requiring the backend to support something just because an external utility wants to optimise the performance of upgrades in a way that may introduce later bugs seems rather questionable to me. You still have to perform a backup of the database prior to upgrade and that also must scan the whole database, so the overall time to upgrade will still vary according to database size. So I don't see any overall benefit, just risk, and I cited a similar situation where that risk has already materialized into damage for a user in at least one case. -- Simon Riggs www.2ndQuadrant.com