On Sat, Aug 09, 2008 at 06:49:18PM +0300, Ibrahim Harrani wrote: > >> Third, you need to > >> > setup your tables/indexes to use a < 100% fill-factor, this will allow > >> > HOT updates to work. > >> > >> # ALTER TABLE dspam_token_data SET ( FILLFACTOR = 100 ); > >> > > You need to use a value for fillfactor that is less than 100%, otherwise any > > update will be forced to use a new data page at the end of the table file > > which will randomize your I/O over time. > > Sorry!.. It should be OK now: > > # ALTER TABLE dspam_token_data SET ( FILLFACTOR = 90 ); Good.
> > >> Are you talking about "id_token_data_sumhits" index on the table? > >> Should I drop it? > OK. > > # DROP INDEX id_token_data_sumhits ; > Good. > What about the PgSQLConnectionCache value? I set it 30.. > This value should be set to the number of simultaneous DSPAM checks that you plan to run. Are you using the dspam server daemon/dspamc? > By the way, I recognized that, While I am training dspam, total > process time increases from 0.3-0.4 seconds to 5-10 seconds. > Do you mean that it takes 5-10 seconds per message? What version of DSPAM did you say that you were using? Do you have slow query logging enabled? If not, turn it on and run "EXPLAIN ANALYZE query" for some typical slow queries. They should all be using indexes and not sequential scans. Ken !DSPAM:1011,489dc450150926834623025!
