Neil Conway wrote:
> Josh Berkus wrote:
> > Wheras integrated AV is something we *could* do, and is widely
> desired.
>
> I don't see why. IMHO the current autovacuum approach is far from
> optimal. If "integrated autovacuum" just means taking the same
> approach and building it into the backend, how does that significantly
> improve matters? (I find it difficult to take seriously answers like
> "it lets us use the backend's hash table implementation"). It _does_
> mean there is more of an implicit stamp of PGDG approval for
> pg_autovacuum, which is something I personally wouldn't want to give
> to the current design.
The reason to integrate it has nothing to do with the hash
implementation, it has to do making autovacuum more accecable to the
masses, and more importantly, it proves a solution (not necerraily the
best solution) to the vacuum problem, which I belive is a problem for
PostgreSQL. Integrating it into the backen also allows autovacuum to be
better than it is now, using the backend logging functions, storing per
table thresholds, solving the O(n2) problem, start up and shutdown
issues and more. I agree that if autovacuum becomes a long term
solution then we should also integrate FSM information etc...
What else is lacking in the current design? Or more specifically what
else would have to be done before you would consider giving it the PGDG
stamp of approval?
Matthew
