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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
