On Mon, 2005-10-10 at 08:16 -0700, Aaron Stone wrote: > 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.
Yes it can. But it isn't necessary in recent versions of sqlite which autovacuum. Now: what IS useful is "ANALYZE" which is like "VACUUM ANALYZE" on Pg, but not everywhere. It's only available >= 3.2.3 but in older versions, it wasn't necessary either (the query optimizer wasn't that smart anyway) ANAYLZE can also be called on a tablename. > 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 > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
