> > > 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.
Agreed, since move==copy+delete I see that this is needed.
> > 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.
No kidding?
It feels like reverse-engineering a closed source database layout.
> 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.
So the pointers would be this way?
Users->Mailboxes->Physmessages
^ ^
| |
messageblks
So..
A mailbox belongs to a user.
A physmessage belongs to a mailbox
A messageblk belongs to a physmessage and a mailbox
That explains a whole lot, but it's not exactly logical.
But I still don't understand exactly how it works, could you please
give me an example of how the relevant data in the 3 affected tables
look before and after a copy?
-=Dead2=-
