On Sat, 19 Dec 2009 17:10:56 +0100 (CET) "Nicolas Grekas" <nicolas.gre...@espci.org> wrote:
> > 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 > Did that already and added this to the header of the purge script: -- --------------------------------------------------------------------------- -- Note: Should you have modified your dspam.conf to have other intervals for -- the purging or you have modified the TrainingMode to be other then -- 'TEFT' then please modify this SQL file to be in sync with your -- dspam.conf. -- -- Note: It is difficult to purge unused tokens with SQL clauses the same way -- as dspam_clean is doing it. So you should still run dspam_clean with -- the "-u" parameter from time to time. -- --------------------------------------------------------------------------- > > Looking good IMHO. Need to quickly test it and then push it to GIT :) > > cool :) > It is already there. I just need to execute "git push". But I wait till I have other things fixed and push everything later today. > for postgre, sorry, I'm not your boy (never used) > You should try it once. You will not feel instantly @home if you are coming from the MySQL area. BUT! It's a great RDBMS and you will quickly realize that PostgreSQL is a real working horse and a cameleon. You can change it to fit for a small installation and you can change it to fit for a very, very huge installation. The only thing that I miss terribly in PostgreSQL is a good, solid and easy to setup replication mechanism. MySQL is much more easier in that regard. But PostgreSQL is not sleeping and the future looks bright. :) > > 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 :) > Well... the optimizer is not that intelligent. Not always. It optimizes but it does not that in such a way that it would reorde that kind of stuff since it would require the optimize to keep track of what has happened in the past and then do the decision for the future. And IMHO the MySQL optimizer does not do that. > thank you for your time and consideration, and btw, thank you for the new > PlusedCharacter config option ! > I HAVE TO THANK YOU. Your submission made me to sit down and rework that purging for MySQL. Would you have not submitted your MySQL purging script then I would not touched again that file. And your submission was/is a inspiration. Good job! Thank you! We are a good working team :) > Nicolas > -- Kind Regards from Switzerland, Stevan Bajić ------------------------------------------------------------------------------ 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
