Michael Monnerie wrote: > On Freitag, 1. Juni 2007 Paul J Stevens wrote: >> Half right. The 512k boundary will be dropped. It was there for >> historical reasons (read: mysql-3.0) and there is no need for it at >> all anymore. The messages will be split into logical first level >> mimeparts: no recursion. > > Even better so. :-) > BLOB fields and 64bit CPUs can even store a complete DVD as a single > attachment :-)
But dbmail wouldn't like 6GB messages except on machines with a *lot* of ram. There's a lot of in-memory copying going on. I've been testing with 1GB messages a while back on a 1GB machine and it wasn't pretty. I removed the most blatantly redundant copying at the time, and it helped, but zero-copy we aint; > >> Definitely. We need an algorithm that will prevent collisions at all >> cost. Such checksums will only be calculated during insertion to >> ensure uniqueness of the attachment so they will not affect the >> retrieval processes (pop/imap). > > Maybe the name of the attachment, and its type, could be stored together > with md5? That should be really enough I think. We could easily provide similar caching facilities for mime parts, as we do for messages. Doing that is however trivial compared with reshuffling the tables as I outlined yesterday. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
