Matthew Schumacher wrote: > Yes, we tried that. I attached another version of the proc that gets > rid of the looping altogether, but believe it or not, it's slower.
Weird... > The reason why we rely on procs is because the SA code doesn't have > transactions yet. By passing the tokens in as an array we get > transactions because pgsql treats each run of a proc as a trans. If your message has only a few tokens, the SELECT * ... WHERE token in (...) runs in a single transaction. [...] > You mean having a separate bdb for each key/val pair? Ouch! No. A separate bdb for each user. And in a cluster of scanning machines, the bdb's are updated on a master and then synchronized to each slave. > As much as I love pgsql and think it's light years beyond mysql in > features, stability, flexibility, and even performance (when doing > complex queries against large tables), I am now testing mysql for my > bayes store. Mysql has one good thing going for it, raw speed on simple > queries, which is really the only requirement for bayes. I've never used MySQL, so I can't comment. But if you want real speed, a well-written BDB implementation will beat either Pg or MySQL. Regards, David. _______________________________________________ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
