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 thi
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
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 ', for
pgsql it calls a 'VACUUM '. For sqlite it calls a 'VACUUM' on
the entire db afaict.
Geo Carncross wrote:
> Furthermore, it should
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 spec
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 ri
