|Main Archive Page > Month Archives > spamassassin-users archives|
On 23/12/11 14:20, Henrik K wrote:
>> As I understand it, if the MySQL query cache is tuned appropriately,
>> then most of the queries should not be touching disk anyway?
> Enabling query cache will probably (marginally) slow things down. Bayes
> queries are extremely random, so there's nothing to cache. Any write to the
> table will invalidate caches anyway. And those writes happen every time a
> token is read (atime is updated).
To stop the query cache being invalidated, it would probably be better
if the writes were queued and then done in batches. Can SpamAssassin
handle this sort of queue internally, or would some sort of additional
technology be required?
I don't know what the point of the atime data is, but is there any need
to update the atime on every read? Could that write be skipped if the
atime is already within a certain period of time? Ie, if the atime has
already been updated in the last 5 minutes, is there any point in doing
-- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F