> Thus I still vote for implementation of the blobs and is_compressed > flag. Are there any negative sides to this approach?
Also, are the messagebodys stored in one large chunk or are they still divided into pieces? If one large chunk, then why not just have one field for header and one for body? That would leave us with just one messageblk for each message, meaning simple unique index searches, smaller indexes, and easier to implement zlib compression of message body only. The problem with this would be that no mails can be bigger than 1GB.. For me that is not a problem as we will limit to 20-50mb, but I do imagine it beeing a problem in the future. What about if we had a single neat table just for the headers? That would be a big advantage for speed when getting headers (ex: webmail would benefit greatly). But this is too big a change for 2.1-2.9, so it would have to be done before 2.0 or wait until 3.0 (~forever). I am stressing this yes, but so far I have recieved no negative feedback, and hardly any positive. Does anyone else have toughts regarding this at all? I feel I am ranting on before a bunch of zombies. Btw, I've gotten a tip that blobs are no good for ascii data and so I guess there would have to be zlib or no zlib. After all, you can't compress with zlib and store in a text field I think. Some releated info (from what I have found of docs): Default for creating table is storage=plain. This means that everything is stored plainly in the table. Creating the table with storage=external This inherits 'plain' And lets big varchar/char/text strings dynamicly be moved out of the table to increase efficency for the rest of the table. Creating the table with storage=extended This inherits 'external' And makes those "moved" strings to be compressed aswell. Maybe it would be worth testing these.. 'External' seems like a good default for me and would require no changes to dbmail to work (except the database creation). If it works well, and my zlib idea is too far off base then 'extended' might be a good choice too, but should be made a install-time option to 'external'. But external and extended are only useful if there is only one big field containing the messagebody since it will not move the smaller ones. If you simply say "NO!", then I'll probably be forced to branch into a separate branch for our company since dbmail in the current form will not fill our needs. I think we need to think more scalable than has been so far, what about taking gmail type of service as an example? We might not get close, but we might well try. Sorry about the long rant, I started out writing only a short message, but I have too much on my heart. -HK
