Am 19.03.2015 um 21:54 schrieb Simon:
On Fri, Mar 20, 2015 at 9:31 AM, Reindl Harald wrote:
Am 19.03.2015 um 21:16 schrieb Simon:
What im trying to understand is why is the SUM of curmail_size
is approx
110GB, yet the database size (even dump'ed) is 400GB. Surely
dbmail does
not have that much overhead in its database?
mailsize has barely to do with database size
completly different worlds
no database at all gives back space just because data are removed
because the overhead would be way too large, be it mysql, berkely
db, postgresql or something else - they all try to re-use allocated
space as good as possible without vacuum all the time
OK thanks for the clarification on this. I just seems completely out of
wack that the DB would use 4 times the amount of space for the actual
data to me :)
One of the reasons we have moved away from dbmail for our primary
platform...
no system is without drawbacksif the size of the database is your largest problem you should ask youself why still use dbmail 2.2 without the single-instance-storage and a outdated mysql 5.1
* dbmail 3.x stores eachmessagepart once with references and if it is identical for several messages you need the sapce only once * mysql 5.5 supports innodb compression * mysql 5.6 / MariaDB 10.x even supports optimize table without lockingin fact all of your storage problems are coming from using legacy software versions and in any case if storage is your primary problem you made mistakes before
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
