Skip site navigation (1) Skip section navigation (2)

Re: bad plan

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-performance(at)postgresql(dot)org>, "Julien Cigar" <jcigar(at)ulb(dot)ac(dot)be>
Subject: Re: bad plan
Date: 2012-04-05 14:26:12
Message-ID: 4F7D65340200002500046BE4@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-performance
Julien Cigar <jcigar(at)ulb(dot)ac(dot)be> wrote:
 
> I tried to play on the various cost settings but it's doesn't
> change anything, except setting random_page_cost to 1 (which will
> lead to bad plans for other queries, so not a solution)
 
Yeah, you clearly don't have the active portion of your database
fully cached, so you don't want random_page_cost to go as low as
seq_page_cost.
 
Here's one suggestion to try:
 
random_page_cost = 2
cpu_tuple_cost = 0.05
 
I have found that combination to work well for me when the level of
caching is about where you're seeing it.  I am becoming increasingly
of the opinion that the default for cpu_tuple_cost should be higher
than 0.01.
 
Please let us know whether that helps.
 
-Kevin

In response to

  • bad plan at 2012-04-05 11:47:33 from Julien Cigar

pgsql-performance by date

Next:From: Scott MarloweDate: 2012-04-05 14:38:20
Subject: Re: postgresql.conf setting for max_fsm_pages
Previous:From: Marcos OrtizDate: 2012-04-05 13:56:44
Subject: Re: postgresql.conf setting for max_fsm_pages

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group