On Sat, Oct 04, 2003 at 11:53:49PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > Imagine having to VACUUM FULL a huge
> > table. Not only it will take the lot required to do the VACUUM in the
> > heap itself, it will also have to rebuild all indexes from scratch.
>
> A very large chunk of VACUUM FULL's runtime is spent fooling with the
> indexes. Have you looked at the code in any detail? It goes like this:
Hmm. No, I haven't looked at that code too much. You are probably
right, of course. Maybe the indexes could be dropped altogether and
then recreated after the vacuum is over, similar to what the cluster
code does. This would be similar to REINDEX, I suppose. (I haven't
actually looked at the REINDEX code either.)
> > I think there are scenarios where the REINDEX will be much worse, say when
> > there are not too many deleted tuples (but in that case, why is the user
> > doing VACUUM FULL in the first place?).
>
> Yeah, I think that's exactly the important point. These days there's
> not a lot of reason to do VACUUM FULL unless you have a major amount of
> restructuring to do. I would once have favored maintaining two code
> paths with two strategies, but now I doubt it's worth the trouble.
> (Or I should say, we have two code paths, the other being lazy VACUUM
> --- do we need three?)
There are two points that could be made here:
1. We do not want users having to think too hard about what kind of
VACUUM they want. This probably botches Bruce's idea of an additional
VACUUM DATA command.
2. We do not want to expose the VACUUM command family at all. The
decisions about what code paths should be taken are best left to the
backend-integrated vacuum daemon, which has probably much better
information than users.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"You knock on that door or the sun will be shining on places inside you
that the sun doesn't usually shine" (en Death: "The High Cost of Living")