Re: Change query join order
| От | Robert Haas |
|---|---|
| Тема | Re: Change query join order |
| Дата | |
| Msg-id | 603c8f071001081155w3b7b8042s362837542cfbc42b@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Change query join order (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Change query join order
|
| Список | pgsql-performance |
On Fri, Jan 8, 2010 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If the other plan does turn out to be faster (and I agree with 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. > > 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. 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
В списке pgsql-performance по дате отправления: