On Mon, 2004-11-01 at 12:31, Paul J Stevens wrote: > Hans Kristian Rosbach wrote: > >>I too am not familiar with the 2.0 schema yet.. And I do think that > >>some of the stuff that has changed since 1.0 were totally useless. > >>I'm going to get digging to see wether this is true or not. > >> > >>I might also propose a whole new schema, but I do not expect it to > >>be used by others than me. > > > > > > Ok, I've looked it over again.. > > > > I see no use for the dbmail_physmessage table. It can as far as I can > > see be merged into dbmail_messages with only very minor fixes. > > Which was the situation pre-2.0 > > The physmessage table was added to the 2.0 setup for good reasons. IIRC, the > main one was making imap copy and move commands *much* cheaper. But I'm sure > Ilja can explain the reasoning a bit better. > > In fact, I dug up Roel's original design considerations: > > http://mailman.fastxs.net/pipermail/dbmail-dev/2003-July/002528.html
Thanks for the explanation.. 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 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? Still I see no use for answered_flag etc in Mailboxes? And the index changes should also be valid. -=Dead2=-
