Re: High load average with PostgreSQL 7.4.2 on debian/ibm eserver.

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

In response to

Browse pgsql-performance by date

  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