Re: Shouldn't we have a way to avoid "risky" plans? - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Shouldn't we have a way to avoid "risky" plans?
Date
Msg-id AANLkTin3xcE9deHQ14kow2b0H_MPZMUmGFm-ZAGfU==z@mail.gmail.com
Whole thread Raw
In response to Re: Shouldn't we have a way to avoid "risky" plans?  (Віталій Тимчишин <tivv00@gmail.com>)
Responses Re: Shouldn't we have a way to avoid "risky" plans?  (Nathan Boley <npboley@gmail.com>)
Re: Shouldn't we have a way to avoid "risky" plans?  (Vitalii Tymchyshyn <tivv00@gmail.com>)
List 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 by date:

Previous
From: Euler Taveira de Oliveira
Date:
Subject: Re: maintenance_work_mem + create index
Next
From: Nathan Boley
Date:
Subject: Re: Shouldn't we have a way to avoid "risky" plans?