Jesse Norell wrote:
Heck, I'm pretty easy-going, either works for me. :) The real advantage to just using a flag is it could probably be done right now - it's quite trivial, and would probably even make the job of header caching easier. To restructure the headers to another table is quite a bit more intrusive, and I'd guess would probably get put off till a later date (remember how long it took the changes to use physmessageblks to stablize?). If the advantages to seperating it (which is just less data to read in a sequential scan, right?) are compelling, keep it on the todo list and do it right (after 2.2 :).
At least part of the reason I am advocating a separate headers table is that I don't see how the header flag would work. I am guessing that you are suggesting adding a flag to the message_blks table that says "this row has headers in it" that is fine but under the current design, a client such as webdbmail would still have to parse that message block to figure out where the headers begin and where the message body begins. Perhaps a hybrid idea would be to add the header flag and then have dbmail only put headers into any row that has that flag set. That way you still get the clean delineation between headers and body and not the intrusive change to the table structure.
Matthew
