put_tokens(), greatest_int(), and least_int() need to be added to maia-

[rjl]

The put_tokens(), greatest_int(), and least_int() procedures specified in

[http://search.cpan.org/src/JMASON/Mail- SpamAssassin-3.1.7/sql/bayes_pg.sql] needs to be added to maia-pgsql.sql. More generally, this maia-pgsql.sql schema should be examined to bring it up to date with the SpamAssassin-supplied bayes_pg.sql.

[anonymous]

I've always wondered when stored procedures were necessary... and this may

be a real case. I wonder what the performance characteristics of this are compared to mysql, where we have observed some slowness on loarge sites, wrt bayes activity.

[anonymous]

Stored procedures would probably help MySQL as well, but adding such a

thing would involve patching SpamAssassin to call those stored procedures--it involves more than just defining the procedures in the schema. The Mail::SpamAssassin::BayesStore::MySQL engine would need to be modified to use those stored procedures, in the same way that the Mail::SpamAssassin::BayesStore::PostgreSQL engine does for put_tokens() and such.

It's worth noting, though, that the SpamAssassin devs most likely opted for stored procedures for their PostgreSQL engine due to how poorly PostgreSQL performed with the generic SQL engine. The performance improvement is said to be very dramatic for PostgreSQL with this PostgreSQL-specific engine, whereas MySQL performed reasonably well with the generic SQL engine to begin with, so the MySQL-specific engine doesn't offer such dramatic improvements. Adding stored procedures to the MySQL engine would probably improve performance somewhat, but it would appear that the SpamAssassin devs decided it wasn't enough of an improvement to justify the additional complexity. The question, I suppose, is did they actually try stored procedures with MySQL, or were they simply using MySQL's out-of-the-box performance as the benchmark they wanted to raise the PostgreSQL Bayes engine's performance to?