Re: New VACUUM FULL

Happy New Year,

On Mon, 2010-01-04 at 11:50 +0900, Takahiro Itagaki wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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