On Thu, May 31, 2007, Paul J Stevens <[EMAIL PROTECTED]> said: > physmsg <- blks > > where we'd need > > physmsg <- blklist -> blks > > That would suggest: > > dbmail_blkslist: > id big int primary key > physmessage_id big int foreign key > messageblk_id big int foreigh key
Add a column for the mime part that the block corresponds to. Also, recall that mime-parts have their own headers -- we can leverage the 'is_header' column to keep track of the headers for each block. For speed (for example, a search query like "find me messages with 'foo.jpg' attached") we should cache those mime-part headers in the headers table we have now, requiring another table to associate between mime part and the cached headers for that mime part. > Call me an optimist, but if those numbers are indeed correct, we may > have to reschedule (provided resources are available). It's not that > much work, and I know how to do it. And 80% or even 50% gain in storage > should be worth something significant even at current storage cost. There's also the significant speedups when requesting single parts for a message. Knowing how to do this isn't the hard part -- you've already written the interfaces to Gmime, so you know how this data comes back -- it's storing and retrieving it in the db that I think will take a while. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
