Matthew T. O'Connor <matthew@zeut.net> said: [snip] >> Breaking out the header names to a table of their own may be useful. >> But doing it just for storage's sake seems a bit overkill given the >> added complexity in constructing queries and maintaining data >> integrity. If it's boosts performance for the target use-cases >> (search,sort,thread) I all for it, if. > > Agreed, the only reason I propose the header_list table is for > performance reasons. This allows the header_values table (which will be > much bigger) to be searched based on an int comparison rather than text > search. I think this is a serious performance boost, but if it's proven > that it's not, then we don't need it.
Once upon a time, I argued this out with... someone (sorry!)... and we came to the conclusion that separating headers from values would be better. [snip] > They also keep the > entire message in one field in the messages table which we don't do > because of the size limitations of MySQL (at least older mysql...) This is a limitation for all databases... you can only prepare a query as large as available memory! I think it would make sense to have *some* sort of mechanism for hangling very large messages. [snip] > The other major thing they have on us is that they manage each MIME > entity inside an email separately. This is an excellent idea. Can GMime parse a message in parts, or does moving to GMime end up requiring the entire message in memory anyways? If that's the case, well, the argument above becomes moot and we need to begin thinking about what our reasonable maximum message sizes are. Aaron
