We went through a lot of pain for a while, basically educating PostgreSQL users about the importance of VACUUM and how the DBMail schema pretty much requires it because of our use pattern. So... I think we have this set up pretty well right now for PostgreSQL.
Can SQLite take a VACUUM against specific tables? In any case, what I'd rather have is admins get used to specifying, "Ok, email is slow for an hour every week on Sunday at 4AM." Rather than frantically posting to the list when email has been slow for days and they don't know why. Aaron On Mon, 2005-10-10 at 16:53 +0200, Paul J Stevens wrote: > 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 >
