Re: [maildb-devel] Re: messages in/out of database

[James S. <jl...@do...>]

li...@av... wrote:
> je...@sq... wrote:
>> Heck, let's err on the side of lots of options.  The idea here is that we
>> can search and sort in a million different ways:
>> [...]
> 
> 
> Errr...that's a lot.  Sure you don't want to keep just the "well-known" 
> ones in msg_ids and shove the rest off into msg_hdrs?  Or do you want to 
> get rid of msg_hdrs and put everything into msg_ids?  Actually I guess 
> we'd need a msg_hdrs in any case to catch anything that we don't account 
> for in msg_ids. Just wondering how far you want to go here.

I think the impact of indexing is going to be our guide here, I'm just 
not sure if there's a difference in performance. I don't know if it's 
faster to put n single-column indexes on one row, or one single-column 
index on n rows, when inserting message headers.

I think RFC 2822 is the latest one governing mail messages...when I get 
a chance I'll see if it calls out required headers. If it does, I say we 
stick to those in msg_ids for a first pass. If not, I say we just do the 
"common" ones and put the optional/variable ones (like X- headers) in 
msg_hdrs.

> 
>> Here's an issue, though: what happens if the value of any of these header
>> lines is longer than the length of the "text" field?
> 
> 
> Well, text is 64k, mediumtext is 16m, and largetext is 4g.  (I misspoke 
> earlier when I said text was 16m.)  So...I'd make them mediumtext, I 
> suspect, since I think 64k may be too small, but 16m has got to be 
> overkill. I mean, I can't even get 1m message bodies sent half the time, 
> much less anything with a header that big.

I'd say even text is overkill...but I don't know if there's a spec limit 
on header length. A big VARCHAR might be more efficient than text. If we 
can't find a reference we may need to do some analysis here.

JLS