Hi Paul, Thanks for your quick reply.
On Thu, 2008-04-24 at 14:59 +0200, Paul J Stevens wrote: > > One is the messagecount (read messages and total) that are displayed for > > a dbmail_mailbox. Counting them everytime is quite a strain on the database. > > That's why in 2.3+ the dbmail_mailbox rows will have a datetime field > (_mtime), > so you can reliably cache results. This timestamp field ma be changed into a > sequence that is updated after each modification of (messages in) that mailbox > to accomodate a RFC for highly concurrent access to shared mailboxes. But this > will be solvable. Sounds neat! > > Secondly, the data retrieved for creating a message row with from > > address. subject, date. message size etc is scattered out along a few > > tables. The query needed for this pretty slow. as it contains a fair > > number of join's. What I'd like to have is a simple table per > > physmessage (or even _in_ dbmail_physmessage) containing the relevant > > information. > > > > Could using stored procedures be a solution to this problem? > > That join should not be *that* slow. It essentially only involves the > dbmail_headervalues and physmessage tables. > > Also, duplication of cached data is *evil*. Consider using the dbmail_envelope > table which contains all the senders, the recipients, date, subject and > message-id information. Of course, it's in a IMAP compatible format, so you'll > need to parse it. One tip: don't use regexp to do that. Write a tokenizer. That's exactly what I wanted! I've completely overlooked that one, I'm very sorry. Thanks, Casper
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
