I just want to give some feedback from our internal testing of this
Attachment table rows: 1593072
Attachment table datafile size: 61G.
It took 105 minutes to extract the attachments.
After extraction, the attachment directory size was 34G.
After a “optimize table rt4.Attachments;” run (which took 40 minutes),
the attachment table datafile size was 13G.
Attachment datafile + attachment directory = 13G + 34G = 47G
Compared to the previously 61G datafile size we saved 14G.
After some checks for duplicate attachments, which this extension only
extract once (which actually isn’t mentioned in the documentation), I
found out that the de-duplication feature saved 1.5G.
There seems to be a significant overhead when saving binary data in MySQL.
The only annoying thing with this extension is, that even if you have it
configured to save attachments on disk, it first saves the attachments
in the DB and you then have to extract them.
This makes an regular “optimize table rt4.Attachments;” necessary.
As this operation locks the table (up to MySQL version 5.6.17), you have
to plan a regularly downtime.
Maybe you can introduce an option to save the attachments directly on disk.