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 it again? -- 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
signature.asc
Description: OpenPGP digital signature
