I think the real problem is that dspam_merge takes forever and a big amout of RAM. If not, as far as I'm concerned, I would be merging (very) frequently, and not bother. By the way, I would think a sequence of SQL queries would be much faster, but I'd need to know how to sum up the token data for several users. I would be inclined to think that a query such as (with 2 being the uid of my group user, and 1,3,4 the uids of my training users):
BEGIN; DELETE FROM dspam_token_data WHERE uid=2; INSERT INTO dspam_token_data SELECT 2,token,sum(spam_hits), sum(innocent_hits), max(last_hit) from token_data where uid IN (1,3,4); COMMIT; Here, it executes in a few seconds, and shouldn't disrupt anything (at least with postgresql). But as I don't know if merging should be done that way ... :) On Tuesday 09 January 2007 10:52, Robin Elfrink wrote: > Marc Cousin wrote: > > Is this setup working well ? > > Not yet. I have removed all users execpt myself; they were complaining :) > > > The problem I see with it is that user1,user2,user3 ... won't have their > > own database., they'll all use default_user's one. > > > > Am I mistaken ? If I'm right, it means we'll 'sacrifice' them because > > they won't have their own token database anymore. > > Correct. I found no other way unfortunately, and response to my question > was also sparse. > > > I have the impression that every time I do something 'big' in my dspam > config, dspam gets really confused and misses a lot of spam. Then again, > it might be that I have all users' training mode set to 'toe', and do > some purging every night, so it might as well be that dspam only has a > record for spam, and no ham, and handles mail with more 'care' because > it has no ham-reference material. I'm speculating about dspam internals > here :) > > Wat I have now is > > <...> > default_user:merged:*,-user1 > default_user:shared:user1 > <...> > > and training mode for all users set to 'toe', except for default_user > and user1, which are set to 'tum'. I now expect dspam to keep the > default_user dictionary somewhat up-to-date even with purging old data. > > It's a bit of a pain in the *ss that every time I try something it takes > a couple of days to see if it turned out well. And an even bigger pain > if it turns out to not work so well :) > > > > Robin
