| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Kaloyan Iliev Iliev <kaloyan(at)digsys(dot)bg>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Change query join order |
| Date: | 2010-01-08 19:55:00 |
| Message-ID: | 603c8f071001081155w3b7b8042s362837542cfbc42b@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, Jan 8, 2010 at 2:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pierre Frédéric Caillaud | 2010-01-09 08:15:11 | Re: Massive table (500M rows) update nightmare |
| Previous Message | Tom Lane | 2010-01-08 19:23:50 | Re: Change query join order |