I wrote: > Well, with db_num_rows() in the tens of thousands one would expect a CPU > hog here! Three calls to db_get_result for every message - and > db_get_result performs seeking every single time, too.
I have checked, and this one gets fixed with my db_get_result optimization. So as soon as I get an answer to my other letter and submit a patch, it's gone. == The "many queries on big FETCH" question is much harder. I could unite queries for all messages into one, but - see below. > Oct 23 11:48:05 localhost dbmail/imap4d[2762]: dbmysql.c,db_query: > executing query [SELECT messageblk FROM dbmail_message > blks blk, dbmail_messages msg WHERE blk.physmessage_id = > msg.physmessage_id AND msg.message_idnr = '1088' ORDER BY > blk.messageblk_idnr ASC] This one is what one probably can't unite with others, as this would yield a query for all messageblk's, and this can reach into hundreds of megabytes for large folders. Doing the other queries for the entire fetch and then querying for each messageblk separately (if it's needed at all) might as yet speed things up. [Better yet, adding a separate table for headers only might speed things up more for typical BODY.PEEK queries (a mailer getting a mailbox index) - but at the cost of mail insertion speed, so it's probably not worth the hassle] But to use big queries for message data then separate queries for messageblk, we'd have to store the results of the big queries in RAM. This would mean, at least, storing dates in some format other than string... But I'll step off the soapbox at this point and wait for the experts to arrive. Yours, Mikhail Ramendik
