On Wed, 31 Aug 2005, Tom Lane wrote:
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> >> I really really do not like proposals to introduce still another kind
> >> of VACUUM. We have too many already; any casual glance through the
> >> archives will show that most PG users don't have a grip on when to use
> >> VACUUM FULL vs VACUUM. Throwing in some more types will make that
> >> problem exponentially worse.
>
> > Yes, but if they're all under the control of autovacuum, then users
> > don't have to worry...
>
> Well, if the proposal comes packaged with an algorithm by which
> autovacuum will use it, that's a different story. What's sticking in
> my craw about this proposal is really that it's assuming detailed manual
> management of vacuuming, which is exactly the thing we've been sweating
> to get rid of.
>
> BTW ... the original Berkeley papers on Postgres make frequent reference
> to a "vacuum daemon", which seems to be essentially what we're trying to
> build with autovacuum. Does anyone know if the Berkeley implementation
> ever actually had auto vacuuming, or was that all handwaving? If it did
> exist, why was it removed?
Well, from my reading of some of the early papers, VACUUM was kind of
different to what it is now. The idea was that expired data would be moved
out the heap and stored else where. A timetravel mechanism could be used
to see previous versions of the row.
It makes sense that they would manage this with a daemon, but I never saw
one. Mind, I wasn't looking for one.
Thanks,
Gavin
