http://bugzilla.spamassassin.org/show_bug.cgi?id=3951
------- Additional Comments From [EMAIL PROTECTED] 2004-11-04 20:33 ------- Regarding bunch size optimization, I don't think it would ever turn out to be the best solution due to the varied nature of different people's email paths (and the varying nature of the message itself). Find bunch sizes that are good for everyone and consistent throughout a release's lifespan would be, I'd imagine, next to impossible, not to mention extra work to maintain. Bunch sizes would never be better optimized more than a dynamic size anyway, since there's no caching benefit for either method. Out of curiosity though, you mentioned before, in Bug 3225, that the reason bunches were used had very little to do with caching. Looking through the list archives (including bugzilla) the bunches were introduced by Sidney, in what he described as to, avoid blowing away the cache. Later when you implemented, you never mentioned any other reasons? What was the reason for bunches, if not the cache issue? Anyway, the temporary table sound like it may be useful for large tables that host many individual bayes databases. I don't foresee it being any faster, than not using one though, for global databases. Perhaps comparing the number of tokens the current user has in their database (bayes_vars.token_count WHERE ID = x) to the total number of tokens in the database (SUM(bayes_vars.token_count) or something better/persistently stored in DB) would determine if using a temporary table would be worth the overhead trade off. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
