Re: Shouldn't we have a way to avoid "risky" plans?

2011/3/24 Віталій Тимчишин <tivv00(at)gmail(dot)com>:
> 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.

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