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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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