Further statistical analisys will be requiered. Since MySQL has been developed thinking in atomic queries, it will be necesarry to test the time to retrieve the four datasets in small queries, against all data in single ones. Not sure of the global effect.
What I don't see proposed is to go all the road down. When message is recieved by dbmail, the header data can be parse out, and write them in a separate table of the message blocks. When dbmail daemons retrieves the data, they can query this table instead of parsing again and again the first messageblock. Seems natural to me since since the messages arrives only one time, but header data is query multiple times. The rest is the same, when message is retrieved, you send all the blocks, and when deleted, you mark for deletion the message, messageblocks and the new header data. Alejandro Marin ----- Original Message ----- From: "Christian G. Warden" <[EMAIL PROTECTED]> To: <dbmail@dbmail.org> Sent: Wednesday, July 02, 2003 10:22 AM Subject: [Dbmail] messageblks > On Wed, Jul 02, 2003 at 09:44:34AM -0600, Jesse Norell wrote: > > With upcoming schema changes (cached headers, etc.), it'd > > probably be worth stepping back and looking at the best way to > > handle message storage, and see what improvements can be made. > > Even something as simple as a messageblk flag as to whether the > > block contains headers or the body could fix the above issue. > > Flagging the messageblk containing the headers would be nice as I > believe it would allow requests for the headers of all messages within a > mailbox to be retrieved in a single query rather than a SELECT ... > LIMIT 1 for each message. > Currently, on mysql at least, retrieving the headers, statuses and sizes > for all messages in a mailbox causes four queries per message. > > xn > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
