casper at bcx
Apr 24, 2008, 1:59 PM
Post #3 of 4
(115 views)
Permalink
|
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
|
