From: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Shouldn't we have a way to avoid "risky" plans? |
Date: | 2011-03-24 08:44:33 |
Message-ID: | AANLkTim-SKShZUxD55ZuHHHLgYuY_MzSSPm6GNYR_fYW@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2011/3/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
> > On Wed, Mar 23, 2011 at 5:29 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >> On 3/23/11 10:35 AM, Claudio Freire wrote:
> >>> * consider plan bailout: execute a tempting plan, if it takes too
> >>> long or its effective cost raises well above the expected cost, bail
> >>> to a safer plan
>
> >> That would actually solve this particular case. It would still require
> >> us to have some definition of "safer" though.
>
> > In my head, safer = better worst-case performance.
>
> If the planner starts operating on the basis of worst case rather than
> expected-case performance, the complaints will be far more numerous than
> they are today.
>
> This can se GUC-controllable. Like plan_safety=0..1 with low default value.
This can influence costs of plans where cost changes dramatically with small
table changes and/or statistics is uncertain. Also this can be used as
direct "hint" for such dangerous queries by changing GUC for session/single
query.
--
Best regards,
Vitalii Tymchyshyn
From | Date | Subject | |
---|---|---|---|
Next Message | Achilleas Mantzios | 2011-03-24 09:11:03 | Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration |
Previous Message | Adarsh Sharma | 2011-03-24 04:52:54 | Re: Re-Reason of Slowness of Query |