Re: bad plan - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: bad plan
Date
Msg-id 4F7D65340200002500046BE4@gw.wicourts.gov
Whole thread Raw
In response to bad plan  (Julien Cigar <jcigar@ulb.ac.be>)
List pgsql-performance
Julien Cigar <jcigar@ulb.ac.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

pgsql-performance by date:

Previous
From: Marcos Ortiz
Date:
Subject: Re: postgresql.conf setting for max_fsm_pages
Next
From: Scott Marlowe
Date:
Subject: Re: postgresql.conf setting for max_fsm_pages