On Fri, 2007-03-16 at 08:40 +0100, Michael Monnerie wrote: > On Donnerstag, 15. März 2007 11:16 Aaron Stone wrote: > > Paul and I write the code that interests us and what we can sell > > support contracts for. This feature would be a lot of work for > > hack-value equal or less than many of the other features we've got on > > the drawing board. If there were a strong business case, that would > > definitely change the equation! > > Although a bit OT to my question, but the idea of storing attachments on > their own sounds very interesting > - remove duplicates, which could for most servers save a certain amount > of disk space (think about those joke .ppt and .avi going to hundrets > of users all the time) > - make stats (hown much disk space saved, average attachment size, which > types are used more often etc.). I love stats, and managers love > stats - you can show them nice graphs how much disk space you saved, > and this saves backup space, you don't need new tapes etc.
Definitely those would be some great stats to have available -- pie charts and all -- to make strong cases for the usefulness of this work. If it takes the same amount of effort to implement either multithreading or attachment sharing, it only makes sense to do multithreading first. This gives a huge performance benefit for the typical use case. > You could adapt the schema without having to change existing e-mail, I > would say - they are stored the old way, and only new e-mail would be > split up. That way, the admin could make a transition easy with > imapsync, or manually by moving e-mails around. To do this would require two parallel code paths, depending upon how the message was stored in the first place. That just doubles the maintenance work. It's better to hammer out one really good new way to do things, then hammer out one really reliable way to transfer the data. > I can't really benchmark this, it's a customers server, no time for > playing around there. Cyrus works, so I won't touch it. I would have > thought that big messages are no problem, as the DB should be much > faster than the network anyway. Even when a message has 100MB, that > would only be 50x512KB to store in messageblks. And to find and > retrieve 50 blocks can't be that hard, especially when there's an > index. I'm sure that the performance is perfectly fine, but it hasn't been specifically benchmarked, so I can't state this as a fact. Certainly you shouldn't migrate email servers unless you're going to have a net benefit for all of the work the migration entails. If that benefit is contingent upon some feature we haven't implemented, you're doing the right thing by waiting. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
