Re: Yet another abort-early plan disaster on 9.3
От | Merlin Moncure |
---|---|
Тема | Re: Yet another abort-early plan disaster on 9.3 |
Дата | |
Msg-id | CAHyXU0xh8kFG6jiH3CLswTPiZTxJYsP==uaZP_w_FxHc0Kyqxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Yet another abort-early plan disaster on 9.3 (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-performance |
On Sat, Sep 20, 2014 at 1:33 PM, Josh Berkus <josh@agliodbs.com> wrote: > For example, we could increase the estimated cost > for an abort-early index scan by 10X, to reflect our weak confidence in > its correctness. Has any progress been made on the performance farm? The problem with suggestions like this (which seem pretty reasonable to me) is that we've got no way of quantifying the downside. I think this is one example of a class of plans that are high risk. Another one off the top of my head is nestloop joins based on assumed selectivity of multiple stacked quals. About 90% of the time, my reflective workaround to these types of problems is to 'disable_nestloop' which works around 90% of the time and the result are solved with monkeying around with 'OFFSET 0' etc. In the past, a GUC controlling planner risk has been much discussed -- maybe it's still worth considering? merlin
В списке pgsql-performance по дате отправления: