I posted about this a couple days ago on dspam-dev...
I am using DSpam with PostgreSQL, and like you discovered the horrible
performance. The reason is because the default PostgreSQL query planner
settings determine that a sequence scan will be more efficient than an
index scan, which is wrong.
On Wed, Nov 24, 2004 at 02:14:18PM +0100, Evilio del Rio wrote:
I have installed the dspam filter
(http://www.nuclearelephant.com/projects/dspam) on our mail server
(RedHat 7.3 Linux with sendmail 8.13 and procmail). I have ~300 users
with a quite low traffic of 4000 messages/day. So it's a
On Fri, 2004-11-26 at 12:13 -0500, David Parker wrote:
I suspect the ultimate answer to our problem will be:
1) aggressive client-side caching
2) SQL tuning
3) more backend hardware
#0 might actually be using connection pooling and using cached query
plans (PREPARE), disabling
On limiting the client side connections: we've been gradually pushing up
the client-side connection pool and threads, and have seen steady
improvement in our throughput up to the current barrier we have reached.
Very well.. Sometimes more simultaneous workers helps, other times it
hinders.
Casey Allen Shobe wrote the following on 11/27/04 03:11 :
I posted about this a couple days ago on dspam-dev...
I am using DSpam with PostgreSQL, and like you discovered the horrible
performance. The reason is because the default PostgreSQL query planner
settings determine that a sequence scan
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Casey Allen
Shobe) wrote:
I posted about this a couple days ago on dspam-dev...
I am using DSpam with PostgreSQL, and like you discovered the horrible
performance. The reason is because the default PostgreSQL query planner
