Giulio Ferro wrote: > All of the above commands took no more than 25 minutes...
Cool. That's fast. Disk IO is not the bottleneck. > > Unfortunately there are still a lot of rows in dbmail_messageblks: > mysql> select count(*) from dbmail_messageblks; > +----------+ > | count(*) | > +----------+ > | 515261 | > +----------+ > 1 row in set (1 min 11.88 sec) > > > > Everything seems to work fine, but as today is Saturday there is > no high traffic and can't say if thigs have improved or not... > > If you say that dbmail_messageblks shouldn't have all those messages, > tell me how I should correct this. It's not the number of rows in messageblks that is your problem, but the rediculous rowscan in the explain output. Could you run that 'explain select' again? Messageblks contains at least two rows for every message. One for the headers, and one or more for the rest of the message in chucks of 500K. You could try dropping the physmessage_id_key index and run the 'explain select' with and without it. Could well be the physmessage_id_index is redundant. In fact, it probably is given that physmessage_id is already declared a foreign key. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
