Re: Shouldn't we have a way to avoid "risky" plans?
От | Merlin Moncure |
---|---|
Тема | Re: Shouldn't we have a way to avoid "risky" plans? |
Дата | |
Msg-id | AANLkTin3xcE9deHQ14kow2b0H_MPZMUmGFm-ZAGfU==z@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Shouldn't we have a way to avoid "risky" plans? (Віталій Тимчишин <tivv00@gmail.com>) |
Ответы |
Re: Shouldn't we have a way to avoid "risky" plans?
Re: Shouldn't we have a way to avoid "risky" plans? |
Список | pgsql-performance |
2011/3/24 Віталій Тимчишин <tivv00@gmail.com>: > 2011/3/23 Tom Lane <tgl@sss.pgh.pa.us> >> >> Claudio Freire <klaussfreire@gmail.com> writes: >> > On Wed, Mar 23, 2011 at 5:29 PM, Josh Berkus <josh@agliodbs.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. ISTM if you add statistics miss and 'risk margin' to the things the planner would have to consider while generating a plan, you are greatly increasing the number of plan paths that would have to be considered for any non trivial query. merlin merlin
В списке pgsql-performance по дате отправления: