From: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
---|---|
To: | eleven(at)ludojad(dot)itpp(dot)pl, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: High load average with PostgreSQL 7.4.2 on debian/ibm eserver. |
Date: | 2004-07-18 09:42:36 |
Message-ID: | 40FA460C.5030108@bigfoot.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
eleven(at)ludojad(dot)itpp(dot)pl wrote:
> Whole config is available here:
> http://ludojad.itpp.pl/~eleven/pg-high-load.conf
effective_cache_size = 4000 # typically 8KB each
#random_page_cost = 4 # units are one sequential page fetch cost
#cpu_tuple_cost = 0.01 # (same)
#cpu_index_tuple_cost = 0.001 # (same)
#cpu_operator_cost = 0.0025 # (same)
These values are too higher for your hardware, try to execute the
explain analyze for the queries that are running on your box and
repeat it lowering these values, I bet postgres is running seq scan
instead of an index scan.
These are the value that I use for a configuration closer to your:
effective_cache_size = 20000
random_page_cost = 2.0
cpu_tuple_cost = 0.005
cpu_index_tuple_cost = 0.0005
cpu_operator_cost = 0.0025
last question, do you use the autovacuum daemon ?
If no => you have to use it
If yes => did you apply the patch that will not fail with
big tables like yours ?
if you can post the autovacuum daemon log ( last lines ).
Regards
Gaetano Mendola
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-07-18 17:23:21 | Re: Insert are going slower ... |
Previous Message | Josh Berkus | 2004-07-18 00:02:20 | Re: Scaling with lazy index updates |