2011/3/24 Віталій Тимчишин <tivv00@xxxxxxxxx>: > 2011/3/23 Tom Lane <tgl@xxxxxxxxxxxxx> >> >> Claudio Freire <klaussfreire@xxxxxxxxx> writes: >> > On Wed, Mar 23, 2011 at 5:29 PM, Josh Berkus <josh@xxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
