Re: Change query join order
От | Kaloyan Iliev Iliev |
---|---|
Тема | Re: Change query join order |
Дата | |
Msg-id | 4B572A1B.50706@digsys.bg обсуждение исходный текст |
Ответ на | Re: Change query join order (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-performance |
<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>
В списке pgsql-performance по дате отправления: