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

Поиск
Список
Период
Сортировка
От Віталій Тимчишин
Тема Re: Shouldn't we have a way to avoid "risky" plans?
Дата
Msg-id AANLkTim-SKShZUxD55ZuHHHLgYuY_MzSSPm6GNYR_fYW@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Shouldn't we have a way to avoid "risky" plans?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Shouldn't we have a way to avoid "risky" plans?
Список pgsql-performance


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. 


--
Best regards,
 Vitalii Tymchyshyn

В списке pgsql-performance по дате отправления:

Предыдущее
От: Adarsh Sharma
Дата:
Сообщение: Re: Re-Reason of Slowness of Query
Следующее
От: Achilleas Mantzios
Дата:
Сообщение: Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration