Received: from localhost (maia-3.hub.org [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 913319FB294
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon,  5 Mar 2007 12:32:53 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024)
	with ESMTP id 15787-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon,  5 Mar 2007 12:32:39 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from nf-out-0910.google.com (nf-out-0910.google.com
 [64.233.182.184])
	by postgresql.org (Postfix) with ESMTP id 4F6429FA43B
	for <pgsql-performance@postgresql.org>;
	Mon,  5 Mar 2007 12:32:39 -0400 (AST)
Received: by nf-out-0910.google.com with SMTP id x4so2163854nfb
	for <pgsql-performance@postgresql.org>;
	Mon, 05 Mar 2007 08:32:38 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=Ir8G4HpxTb3udEiNjR508tqeJrUfD81tbL6NkrgTjK4UoqMnm0NlKvxpkx6if+RANLyTuRnzsSrCJaOmQrUOKZQcbnL5hcFt0aI+mmUplRRDn9+O611o7aY27yF+U2bnGYgAYpiy1nJExi6SXe6YgH5y609q8xBJ2uB6CuZfXXI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=dx963+BOMxqvK7gqarn6d+XXo+xSnJZn1pmNogJsiLuMrPLPxNbJNx8LXk+bfXjuvYodJ3Fplb7wmUZyaLR0QToea1oP5xOsVwf2yHbcSk7oXtEHSiuPOSep3gfW2l8whPsFjmXCtgXwY2wzza/VFBAUupH6ClwknRllnAEEaWw=
Received: by 10.82.177.3 with SMTP id z3mr5313661bue.1173111930213;
	Mon, 05 Mar 2007 08:25:30 -0800 (PST)
Received: from ?192.168.1.34? ( [81.107.202.67])
	by mx.google.com with ESMTP id c22sm14781930ika.2007.03.05.08.25.28;
	Mon, 05 Mar 2007 08:25:28 -0800 (PST)
Message-ID: <45EC4477.4020702@enterprisedb.com>
Date: Mon, 05 Mar 2007 16:25:27 +0000
From: Heikki Linnakangas <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.8 (X11/20061116)
MIME-Version: 1.0
To: Aidan Van Dyk <aidan@highrise.ca>
CC: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
References: <esh2mg$16vu$1@news.hub.org> <45EC1931.3020701@enterprisedb.com>
	<esh858$2iiv$1@news.hub.org> <45EC2CCF.8020906@enterprisedb.com>
	<20070305151820.GC25573@yugib.highrise.ca>
In-Reply-To: <20070305151820.GC25573@yugib.highrise.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200703/93
X-Sequence-Number: 23498

Aidan Van Dyk wrote:
> * Heikki Linnakangas <heikki@enterprisedb.com> [070305 09:46]:
>> 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

Good point, I didn't remember that. Using cluster in an environment like 
the OP has, cluster might actually break the consistency of concurrent 
transactions.

> But the documents don't mention anything about cluster being unsafe.

Really? <checks docs>. Looks like you're right. Should definitely be 
mentioned in the docs.

> AFAIK, Vacuum full doesn't suffer the same MVCC issues that cluster
> does.  Is this correct?

That's right. Vacuum full goes to great lengths to be MVCC-safe.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com