Re: New VACUUM FULL - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: New VACUUM FULL
Date
Msg-id 1262592275.19367.31795.camel@ebony
Whole thread Raw
In response to Re: New VACUUM FULL  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: New VACUUM FULL
Re: New VACUUM FULL
List pgsql-hackers
Happy New Year,

On Mon, 2010-01-04 at 11:50 +0900, Takahiro Itagaki wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
> 
> > So, what is the roadmap for getting this done?  It seems like to get
> > rid of VFI completely, we would need to implement something like what
> > Tom described here:
> > 
> > http://archives.postgresql.org/pgsql-hackers/2009-09/msg00249.php
> > 
> > I'm not sure whether the current patch is a good intermediate step
> > towards that ultimate goal, or whether events have overtaken it.
> 
> I think the most desirable roadmap is:
>     1. Enable CLUSTER to non-critical system catalogs.
>     2. Also enable CLUSTER and REINDEX to critical system catalogs.
>     3. Remove VFI and re-implement VACUUM FULL with CLUSTER-based approach.
>        It should be also optimized as Simon's suggestion.
> 
> My patch was intended to do 3, but we should not skip 1 and 2. In the roadmap,
> we don't have two versions of VACUUM FULL (INPLACE and REWRITE) at a time.
> 
> I think we can do 1 immediately. The comment in cluster says "might work",
> and I also think so. CLUSTERable toast tables are obviously useful.

You make some good points.

I would prefer this slightly modified version

1. Commit your patch, as-is (you/me)
2. Work on infrastructure for VFC (VACUUM FULL using CLUSTER) for system
relations (Simon)
3. Enable CLUSTER and REINDEX on critical system catalogs (Itagaki)
4. Optimise VFC, as discussed earlier (Itagaki)

I have put names in brackets, but this is just a suggestion.

This differs from your sequence in only a few ways
* We implement the basic VFC now, so everybody knows what we have
* We separate the infrastructure for (2) from the enabling of this
infrastructure for CLUSTER and REINDEX. There may be additional issues
to consider for those cases and we should think through and test them as
a different task
* We do not remove VFI in this release

This is a more cautious approach. Completely removing VFI in this
release is a big risk that we need not take; we have little to gain from
doing so and putting it back again will be harder. I am always keen to
push forwards when a new feature is worthwhile, but cleaning up code is
not an important thing this late in release cycle.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Next
From: Hitoshi Harada
Date:
Subject: Re: PATCH: Add hstore_to_json()