Furthermore, it should be backend-specific: SQLite never requires a vacuum- it never buys anything (when autovacuum is turned on), but this has and may change again. It's certainly version-specific, but because it has to lock the entire database, it would seem that doing a vacuum on SQLite without the user knowing it would almost always be a very bad idea.
PostgreSQL could get a VACUUM ANALYZE- but only after running dbmail after new activity- but then, we've gone to a lot of work to make sure the Pg queries we've selected cause the "right path" to be chosen. Because the reasons for vacuuming are different on different backends, this really should be moved. MySQL might not require vacuuming either, but who knows, it may be a useful hook for the dbmail backend to have. On Sun, 2005-10-09 at 19:54 -0400, Matthew T. O'Connor wrote: > I noticed today that while running dbmail_util -ay at the end of the job > it performs a vacuum against the entire database that dbmail is in. I > think this is a little wrong since we don't know what other tables are > in the database, and it's wrong to assume that we can or should vacuum > every thing in the database. I think it would be better to run the > vacuum command against the specific dbmail_* tables. > > Thoughts? > > Matt > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
