Re: Optimization idea - Mailing list pgsql-performance

From Robert Haas
Subject Re: Optimization idea
Date
Msg-id y2y603c8f071004230405r5fcef546l3da84c407ce2655a@mail.gmail.com
Whole thread Raw
In response to Re: Optimization idea  (Vlad Arkhipov <arhipov@dc.baikal.ru>)
Responses Re: Optimization idea
Re: Optimization idea
List pgsql-performance
On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov <arhipov@dc.baikal.ru> wrote:
> I don't think this is just an issue with statistics, because the same
> problem arises when I try executing a query like this:

I'm not sure how you think this proves that it isn't a problem with
statistics, but I think what you should be focusing on here, looking
back to your original email, is that the plans that are actually much
faster have almost as much estimated cost as the slower one.  Since
all your data is probably fully cached, at a first cut, I might try
setting random_page_cost and seq_page_cost to 0.005 or so, and
adjusting effective_cache_size to something appropriate.

...Robert

pgsql-performance by date:

Previous
From: Vlad Arkhipov
Date:
Subject: Re: Optimization idea
Next
From: Cédric Villemain
Date:
Subject: Re: Optimization idea