> Here I have to intercept. That 0.35 to 0.65 is not that easy to compute
Ok, I read libdspam.c:_ds_calc_stat, not that easy :) So we have to remove the related query and sql variable > Looking good IMHO. Need to quickly test it and then push it to GIT :) cool :) for postgre, sorry, I'm not your boy (never used) > btw: I have done some quick tests with MySQL 5.1.41 and the additional > indices. On a InnoDB table adding those indices do not speed up the purging. I don't have enough data to test, my suggestion is mainly "theoretical" on this point... > I would reorder that where condition. I would first check for the preference > value since on normal setups the preference table is way > And here I would reorder the conditions as well. About reordering, I don't have many ideas... I'm not very used to this level of optimisation. I make the assomption that the mysql optimizer will do the job for me :) thank you for your time and consideration, and btw, thank you for the new PlusedCharacter config option ! Nicolas ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
