<tt>Thanks You,<br /> I changed the random_page_cost to 2 and the query plan has changed and speeds up.<br /> I will
checkthe other queries but I think I will leave it at this value.<br /><br /> Thank you again.<br /> Kaloyan Iliev<br
/><br/></tt><br /> Robert Haas wrote: <blockquote
cite="mid:603c8f071001081155w3b7b8042s362837542cfbc42b@mail.gmail.com"type="cite"><pre wrap="">On Fri, Jan 8, 2010 at
2:23PM, Tom Lane <a class="moz-txt-link-rfc2396E" href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a> wrote:
</pre><blockquotetype="cite"><blockquote type="cite"><pre wrap="">If the other plan does turn out to be faster (and I
agreewith Tom
that there is no guarantee of that), then one thing to check is
whether seq_page_cost and random_page_cost are set too high. If the
data is all cached, the default values of 4 and 1 are three orders of
magnitude too large, and they should also be set to equal rather than
unequal values. </pre></blockquote><pre wrap="">Tweaking the cost parameters to suit your local situation is the
recommended cure for planner misjudgments; but I'd recommend against
changing them on the basis of only one example. You could easily
find yourself making other cases worse. Get a collection of common
queries for your app and look at the overall effects. </pre></blockquote><pre wrap="">
No argument, and well said -- just trying to point out that the
default values really are FAR too high for people with databases that
fit in OS cache.
...Robert
</pre></blockquote>
