On Mon, 01 Nov 2004 13:27:59 +0100, Hans Kristian Rosbach
<[EMAIL PROTECTED]> wrote:
>
>
> > So, in order to get one message we need to look it up in this order:
> > Users->Mailboxes->Physmessages->mailblks
> >
> > Well, this sucks.. But I guess it's nice for IMAP users. But does
No, it doesn't suck. Explanation below. :)
> > people actually copy messages that much? I've never done so myself,
> > and I don't really see any big use for it. In my openion it is not
> > worth it to make everything else slow and complex in order to speed
> > up a seldomly used function. The move argument is not true I think,
> > couldn't that be just as easily done using a simple update?
>
> Well, I've taken a good look at it again.. And I cannot really see
> that this is true..
You cannot do a copy using an update.
>
> Physmessages is not a layer between Mailboxes and Mailblks.
Roel's original idea was a layer between mailboxes and messages. I
changed that to a layer between messages and messageblocks.
>
> Physmessages only contains one id (it's own), and both
> Mailboxes and Mailblks point to physmessages using that id.
> So I still see no gain from using the Physmessages table.
>
> CREATE SEQUENCE dbmail_physmessage_id_seq;
> CREATE TABLE dbmail_physmessage (
> id INT8 DEFAULT nextval('dbmail_physmessage_id_seq'),
> messagesize INT8 DEFAULT '0' NOT NULL,
> rfcsize INT8 DEFAULT '0' NOT NULL,
> internal_date TIMESTAMP WITHOUT TIME ZONE,
> PRIMARY KEY(id)
> );
>
> See, it would need another id in there to be able to point
> one mailblks into several mailboxes.
>
> Once again.. Is there any logic behind this in it's current layout?
I think you're a bit confused. Your earlier point that DBMail database
layout needs documentation is very valid here.
Let me try to explain how the physmessage (for physical message) works.
A message in the messages table can be called a virtual message, but
I'll just refer to it as 'message':
Originally (dbmail 1.x) , when copying a message the following woudl happen:
1. a new entry in the messages table was made.
2. the message blocks of the original message was copied
step 2 costs a lot of time. As IMAP COPY commands are very frequent
(e.g. when moving a lot of messages from one mailbox to another)
I created a layer in between:
an entry physmessage in physmessage is related to one or more messagblocks.
every message in the messages table points to *one* physmessage entry.
However, there can be several messages pointing at the same
physmessage entry. Now, a copy will result in the following operation:
1. enter a new record in the messages table pointing at the same physmessage.
This is fast. And certainly much faster than copying the whole message
to a new set of message blocks. The new entry in messages still has
it's own set of flags, so they can be set independently.
Hope this clears things up.
Ilja
