> 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

Reply via email to