Tom Lane wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I suggest that we change vacuum to only move remove tuples if there is
> > more than 20% expired tuples.
>
> > When we do vacuum, we drop all indexes and recreate them.
>
> > This fixes the complaint about vacuum slowness when there are many
> > expired rows in the table. We know this is causes by excessive index
> > updates. It allows indexes to shrink (Jan pointed this out to me.) And
> > it fixes the TOAST problem with TOAST values in indexes.
>
> 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.
I can see some value in having a _configurable_ threshold %age of
deletes before vacuum kicked in and attempted to shrink table/index
on-disk file sizes. This would let the end-user decide, and 20% is
probably a reasonable default, but if it isn't then changing a default
is easier to do down the track.
I can also see that it could be done with (perhaps) a modification to
VACUUM syntax, say:VACUUM [VERBOSE] [SHRINK] ...
And I believe that the whole thing will go better if ANALYZE is taken
_out_ of vacuum, as was discussed on this list a month or two ago.
Cheers, Andrew.
--
_____________________________________________________________________ Andrew McMillan, e-mail:
Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
