> We can't "drop and recreate" without a solution to the relation
> versioning issue (unless you are prepared to accept a nonfunctional
> database after a failure partway through index rebuild on a system
> table). I think we should do this, but it's not all that simple...
>
> I do not see what your 20% idea has to do with this, though, nor
> why it's a good idea. If I've told the thing to vacuum I think
> it should vacuum. 20% of a big table could be a lot of megabytes,
> and I don't want some arbitrary decision in the code about whether
> I can reclaim that space or not.
Well, I think we should do a sequential scan before starting vacuum to
find the number of expired rows.
Now that we are removing indexes, doing that to remove a few tuples is a
major waste. The user can not really know if the table is worth
vacuuming in normal use. They are just going to use the default. Now,
I think a FORCE option would be good, or the ability to change the 20%
default.
Remember, commercial db's don't even return unused space if you remove
all the rows in a table. At least Informix doesn't and I am sure there
are others. I like vacuum, but let's not make it do major hurtles for
small gain.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
