Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL database persistence.

2005-07-20 Thread Matthew Schumacher
Sevo Stille wrote: > Matthew Schumacher wrote: > > At any rate with my installation, SA/pg seems to be mostly slowed down > by the fact that the database is poorly indexed - indexing the most > significant search fields (bayes_seen(msgid), bayes_token(token) and id > throughout all tables) and do

[Mimedefang] Newbie question - testing

2005-07-20 Thread Daniel C. Mahoney
I've been through all the docs I can find online and still haven't been able to find an answer. I'm a former qmail user, having to relearn sendmail at a new employer. One of my first tasks is to fix the broken installation of SpamAssassin+ClamAV+MIMEDefang. I've got the individual component pa

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL database persistence.

2005-07-20 Thread Sevo Stille
Matthew Schumacher wrote: > In fact I looked that the performance benchmarks on the spamassassin > site: http://wiki.apache.org/spamassassin/BayesBenchmarkResults and they > show postgres to be a terrible performer which would be true if the are > not using persistent database connections. Going

Re: [Mimedefang] Script for categorizing spam by hits?

2005-07-20 Thread James Ebright
On Tue, 19 Jul 2005 12:49:26 -0700, Johann wrote > Thank You! I hadn't really thought about a more detailed analysis > than what GraphDefang does, but this is really cool. A little css, a > little php, and viola! http://mail.srar.com/stats/stats.php . > Justification for tweaking the dang thing

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL database persistence.

2005-07-20 Thread David F. Skoll
[EMAIL PROTECTED] wrote: > I agree, though, why call untie_db at all? Because if you're using a Berkeley DB, then each user has his/her own file, and if you scan mail for different users with the same spamd process, then you need to be able to switch database files. The SA people should really a

RE: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL database persistence.

2005-07-20 Thread Matthew.van.Eerde
Matthew Schumacher wrote: > The only thing the untie_db code does in the SQL module is disconnect > from the database. Since there is never a reason to do that unless we > are exiting (in which case it's cleaned up anyway) I commented out the > disconnect and undef statements. > > I can now see p

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread David F. Skoll
Matthew Schumacher wrote: > The only thing the untie_db code does in the SQL module is disconnect > from the database. Since there is never a reason to do that unless we > are exiting (in which case it's cleaned up anyway) I commented out the > disconnect and undef statements. That should be saf

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread Matthew Schumacher
David F. Skoll wrote: > Matthew Schumacher wrote: > > >>It looks like the code is supposed use persistent connections: > > > That's bogus, though; there are many explicit calls to untie_db > sprinkled in the code. It might just be a safety check in case > someone calls tie_db twice. > The on

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread David F. Skoll
Matthew Schumacher wrote: > One thing I did to make this a little better is I found everywhere in > the code where min() and max() are used and created an index on the > column used. Right; that should help. > At this point it is holding up to my mail load, so I'm on the fence > with going back

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread Matthew Schumacher
David F. Skoll wrote: > I should also note that there are many problems with the code, > especially because it makes many assumptions about MySQL-like > optimizations. For example, the code to check if "too many" tokens > will be deleted by an expire run is just plain stupid. > The query to check

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread Matthew Schumacher
David F. Skoll wrote: > Matthew Schumacher wrote: > > >>It looks like the code is supposed use persistent connections: > > > That's bogus, though; there are many explicit calls to untie_db > sprinkled in the code. It might just be a safety check in case > someone calls tie_db twice. > > I sho

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread David F. Skoll
Matthew Schumacher wrote: > It looks like the code is supposed use persistent connections: That's bogus, though; there are many explicit calls to untie_db sprinkled in the code. It might just be a safety check in case someone calls tie_db twice. I should also note that there are many problems w

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread Matthew Schumacher
[EMAIL PROTECTED] wrote: > schu wrote: > >>So the question is, is there a way to make SA use persistent >>connections? I read though the docs and didn't see anything. >>Perhaps a way to create a persistent connection in MD and pass it to >>the SA module? > > > Some thoughts... > > 1. spamd >

Re: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread David F. Skoll
[EMAIL PROTECTED] wrote: > spamassassin calls through the "spamassassin" command and the > Mail::SpamAssassin perl modules don't live long enough to hold on to > a persistent connection. Yes, they do (in MIMEDefang, anyway). They live for the lifetime of a MIMEDefang slave, typically 100 message

RE: [Mimedefang] Mail::SpamAssassin::BayesStore::SQL databasepersistence.

2005-07-20 Thread Matthew.van.Eerde
schu wrote: > So the question is, is there a way to make SA use persistent > connections? I read though the docs and didn't see anything. > Perhaps a way to create a persistent connection in MD and pass it to > the SA module? Some thoughts... 1. spamd spamassassin calls through the "spamassass

Re: [Mimedefang] Script for categorizing spam by hits?

2005-07-20 Thread Renaud PASCAL
Le Mardi 19 Juillet 2005 21:49, Johann a écrit : > > Renaud PASCAL wrote: > > > > Well, not exactly the same slices, and not in the same cols/rows order, > > also, hum, let's say "the beautifying is quite rough" ... > > but it may give you a start ;-) > > > > # gawk '/spam,/{ v[int( $4/5)]++}; E