Re: curmail_size vs innodb disk usage

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 drawbacks

if 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 locking

in 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

_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlULOxYACgkQhmBjz394Anl0tACgg5pRC7V7mDr8hcrBLSdwMm/x
QMoAnjqMMiBQH/EGTI+BLsfPfM3V5jLZ
=Ve4q
-----END PGP SIGNATURE-----