Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id D3B139FA492 for ; Mon, 5 Mar 2007 11:51:38 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 94711-05 for ; Mon, 5 Mar 2007 11:51:20 -0400 (AST) X-Greylist: delayed 00:33:04.712001 by SQLgrey-1.7.4 Received: from yugib.highrise.ca (yugib.highrise.ca [205.150.199.213]) by postgresql.org (Postfix) with ESMTP id 0280B9FB231 for ; Mon, 5 Mar 2007 11:51:26 -0400 (AST) Received: from localhost (yugib.highrise.ca [205.150.199.213]) by yugib.highrise.ca (Postfix) with ESMTP id 43D41111D87; Mon, 5 Mar 2007 10:18:20 -0500 (EST) Date: Mon, 5 Mar 2007 10:18:20 -0500 From: Aidan Van Dyk To: Heikki Linnakangas Cc: pgsql-performance@postgresql.org Subject: Re: PostgreSQL 8.2.3 VACUUM Timings/Performance Message-ID: <20070305151820.GC25573@yugib.highrise.ca> References: <45EC1931.3020701@enterprisedb.com> <45EC2CCF.8020906@enterprisedb.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline In-Reply-To: <45EC2CCF.8020906@enterprisedb.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=BAYES_50, SPF_PASS X-Spam-Level: X-Archive-Number: 200703/111 X-Sequence-Number: 23516 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Heikki Linnakangas [070305 09:46]: > >If that is the case, why would anyone use the vacuum full approach if they > >could use the cluster command on a table/database that will regen these > >files for you. It almost seems like the vacuum full approach would, or > >could, be obsoleted by the cluster command, especially if the timings in > >their respective runs are that different (in our case the vacuum full took > >15 minutes in our worst case, and the cluster command took under 1 second > >for the same table and scenario). > > In fact, getting rid of vacuum full, or changing it to work like > cluster, has been proposed in the past. The use case really is pretty > narrow; cluster is a lot faster if there's a lot of unused space in the > table, and if there's not, vacuum full isn't going to do much so there's > not much point running it in the first place. The reason it exists is > largely historical, there hasn't been a pressing reason to remove it either. I've never used CLUSTER, because I've always heard murmerings of it not being completely MVCC safe. From the TODO: * CLUSTER o Make CLUSTER preserve recently-dead tuples per MVCC requirements But the documents don't mention anything about cluster being unsafe. AFAIK, Vacuum full doesn't suffer the same MVCC issues that cluster does. Is this correct? a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. --CdrF4e02JqNVZeln Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF7DS8uVxNPsxNPScRApGWAJ9XBwbxbI8y3c1/VXScDKPxNBO1fgCfTrB9 B1JrVpDy4YXLGYxN9AX5EAc= =Fms+ -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln--