Re: pg_plan_advice - Mailing list pgsql-hackers

From Haibo Yan
Subject Re: pg_plan_advice
Date
Msg-id CABXr29GDqE4nuS5QneoxtF-pxxVngCZVBGR9Z2H_U0=h2FM2QA@mail.gmail.com
Whole thread Raw
In response to Re: pg_plan_advice  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> Does the plan end up disabled in that case?

I understand that except for join order advice which might not be honored(due to GEQO's randomness), other forms of advice—like scan types or join methods—remain effective since those operations are inevitable parts of the plan regardless of the specific tree structure.
Thanks for the explanation regarding the design philosophy. It clarifies that the primary goal is stabilizing plans within the optimizer's valid search space rather than forcing impossible paths. I will keep the geqo_threshold adjustment in mind if strict structure enforcement is ever needed.
Regards
Haibo

On Thu, Jan 8, 2026 at 11:53 AM Robert Haas <robertmhaas@gmail.com> wrote:
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 can actually 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 by date:

Previous
From: Peter Smith
Date:
Subject: Fix how some lists are displayed by psql \d+
Next
From: Masahiko Sawada
Date:
Subject: Re: Wake up autovacuum launcher from postmaster when a worker exits