Re: PostgreSQL 8.2.3 VACUUM Timings/Performance - Mailing list pgsql-performance

From Heikki Linnakangas
Subject Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
Date
Msg-id 45EC4477.4020702@enterprisedb.com
Whole thread Raw
In response to PostgreSQL 8.2.3 VACUUM Timings/Performance  ("Bruce McAlister" <bruce.mcalister@blueface.ie>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]