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
>
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 wil
> 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.
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), disabli
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.
