So I checked. It is backend-specific, and it's limited to the tables as specified in db.c: DB_TABLENAMES
i.e. For mysql db_do_cleanup calls 'OPTIMIZE TABLE <tablename>', for pgsql it calls a 'VACUUM <tablename>'. For sqlite it calls a 'VACUUM' on the entire db afaict. Geo Carncross wrote: > 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 >>[email protected] >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
