Jesse Norell wrote:
SELECT DISTINCT(physmessage_id) FROM dbmail_messageblks WHERE
messageblk LIKE '%Aaron%';
19066 rows in set (12.81 sec)
So it takes about 35% of the time, but returned 190% of the rows. We'll
have to combine this time trial with the header parser to see which adds
more time per message. My guess is the header parser, but we'll just have
to see.
I'd guess that would be true for a small installation, but we need to
keep large installation performance in mind, too - if you have one database
server and N imap servers, it's a lot easier to move the load to the N (and
add more if neccessary) than to rebuild the one with more horsepower. So
far the discussions have seemed to benefit both, but something like this
one would make a difference (35% of the load on the rdbms).
Along these lines, and admittedly maybe not a great idea, would it seem
desirable to add a config item that sets a "mode" for dbmail that either
does as much work itsself vs. using the database features, or vice-versa?
Might not be terribly useful, but if you could make dbmail perform at it's
peak no matter which kind of setup...
Please not, it becomes another permutation to test! Move the work
to the client! 65% server work and 35% client work adds upp to
100% if the client and server are running on the same machine,
otherwhise we can offload the server a little bit.
The only question remaining, is how expensive is it to move data
from the server to the client?
Magnus
