Re: Thoughts on maintaining 7.3 - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Thoughts on maintaining 7.3
Date
Msg-id 200310091936.h99JaCu29438@candle.pha.pa.us
Whole thread Raw
In response to Re: Thoughts on maintaining 7.3  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Added to TODO:
* Have VACUUM FULL use REINDEX rather than index vacuum

---------------------------------------------------------------------------

Alvaro Herrera wrote:
> 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")
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Thoughts on maintaining 7.3
Next
From: Dennis Bjorklund
Date:
Subject: Re: Isolation levels READ UNCOMMITTED and REPEATABLE READ