> Hi DSPAM community,
>
> For myself, I really appreciate having the conversations about problems
> and solutions with DSPAM being carried out on the mailing list. It allows
> me to save a personal copy of key messages and provides a historical
> archive to search for answers. IRC conversations are only known to those
> who happened to be on-line at the time and then there is no record.
>
> Steve and Ion, I would like to thank you for all the hard work you have put
> into the DSPAM project. We are going to be upgrading our DSPAM infrastructure
> over the summer to version 3.9.0+ and hopefully switch from a MySQL backend
> to a PostgreSQL backend. As a start I have built 3.9.0 on a Solaris 8 box
> against PostgreSQL 8.4.2. My current project is to allow for an option to
> have the PostgreSQL driver use out-of-band binary transmission of query
> parameters. This will have two benefits. First, less CPU will be used since
> the atoi() calls will not be needed to send the data. Second, the size of
> the transmitted data will be reduced by 70% or more in the worst case of
> looking up the tokens. This is more important when the DSPAM DB is on a
> separate machine from the actual engine.
>
> The first cut will be using the libpqtypes.h library to do the work.
> Then I will do some comparisons between the binary transmission and
> the current non-binary transmission of the query parameters. Is this
> something that you would be interested in having folded back in to
> the DSPAM codebase?
>
A big YES from me.
> Regards,
> Ken
>
Hi DSPAM community/developers,
I have been working on the update to the DSPAM PostgreSQL driver to
support binary out-of-band parameter transmission as well as other
performance optimizations. My goal is to make it a via backend alternative
for a high performance DSPAM installation. For code clarity reasons, I
would like to suggest the following changes to the non-binary parameter
version as well:
1. Remove the libdspam support for NUMERIC(20) and only include the
BIGINT support.
I sent in the original patch when PostgreSQL 7.x was the current
release. In our testing, using the NUMERIC() option made the
performance so beneath that of the MySQL driver that it would
not be considered, even for very small DSPAM installations.
2. Announce a minimum PostgreSQL version requirement of 8.1 for non-
Windows and 8.2 for Windows. Or if there is consensus, require
version 8.2 or higher for all.
Version 8.1 was the first release of PostgreSQL to support the
GREATEST() SQL function. Currently the code is using a more
confusing alternative CASE... statement to do the same thing.
This would allow all the drivers to use much clearer and more
similar code in the dspam_token_data UPDATE paths. Another
plug for making 8.2 the minimum version, other than the lack
of Windows support for 8.2, is that they added support for
multiple-row VALUES clauses, like MySQL and SQLite. This
would allow for some more reconvergence of the driver.
The release date for PostgreSQL 8.1 is 8 November 2005 and
for PostgreSQL 8.2 is 5 December 2006 which is still almost
4 years ago.
I think that these changes would improve the performance of the
PostgreSQL driver to an enterprise level while making the codebase
closer to the other drivers which will improve manageability and
make consistent and correct changes to all drivers easier.
Would anyone using DSPAM with the PostgreSQL driver/backend send
me an E-mail with your version of DSPAM and PostgreSQL, the
size of your DSPAM installation in users, and if you think adding
a minimum version requirement for the database backend is acceptable.
I will tally the responses and send an update next Friday.
Cheers,
Ken
------------------------------------------------------------------------------
_______________________________________________
Dspam-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-user
