Josh Berkus wrote:
> Not that I don't agree that we need a less I/O intense alternative to VACUUM,
> but it seems unlikely that we could actually do this, or even agree on a
> spec, before feature freeze.
I don't see the need to rush anything in before the feature freeze.
> 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.
-Neil
