Re: pg_plan_advice
| От | Robert Haas |
|---|---|
| Тема | Re: pg_plan_advice |
| Дата | |
| Msg-id | CA+TgmoYD55R8XqgbFbKhC4Uipu-gxA1msDOsUAZ9q38iCN8dQA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_plan_advice (Haibo Yan <tristan.yim@gmail.com>) |
| Ответы |
Re: pg_plan_advice
|
| Список | pgsql-hackers |
On Wed, Jan 7, 2026 at 5:47 PM Haibo Yan <tristan.yim@gmail.com> wrote: > Instead, the planner seems to silently ignore the structural constraint of the advice and falls back to a path GEQO canactually find. Does the plan end up disabled in that case? > I believe this behavior is acceptable because pg_plan_advice is intended to stabilize plans that the optimizer can generate.Since GEQO cannot generate Bushy plans, users should not be supplying them. Right, I agree. A core principal here is that you can only nudge the planner towards a plan it would have considered anyway. In the case of GEQO, there is some randomness to which plans are considered. Your advice will only be reliably take into account if it applies to elements that must be part of the final plan. For instance, if you advise the use of a sequential scan or an index scan, that should work, because that relation has to be scanned somehow. Advice on a join method should almost always work, since it can apply to any non-leading table. Of course, you also won't be able to advise an infeasible join method, but that would be true without GEQO, too. Advice on the join order is going to be iffy when using GEQO -- if a compatible join order is highly likely to be considered, e.g. because you specify something like JOIN_ORDER(just_one) that only sets the driving table -- then it'll probably work, but if you give a complete join order specification, it probably won't. If you want to avoid that, you can adjust geqo_threshold. Thanks for looking into this. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: