On Tuesday, March 3, 2026, Robert Haas <[email protected]> wrote:
> > > > However with below SEQ_SCAN is applied/matched, but marked as failed > > (so bug?): > > > > postgres=# set pg_plan_advice.advice to 'SEQ_SCAN(t1@minmax_1)'; > > SET > > postgres=# explain (plan_advice, costs off) select max(id) from t1; > > QUERY PLAN > > ----------------------------------------------- > > Aggregate > > -> Seq Scan on t1 > > Supplied Plan Advice: > > SEQ_SCAN(t1@minmax_1) /* matched, failed */ > > Generated Plan Advice: > > SEQ_SCAN(t1) > > NO_GATHER(t1) > > I think this is just out of scope for now. It's documented that we > don't have a way of controlling aggregation behavior at present. Here > again, we can do more things in future releases, but it's too late to > add more to the scope for this release. There's still plenty of time > to fix bugs, but this isn't a bug. We'd need a whole lot of new > machinery to prevent this sort of thing, including new core hooks and > new syntax. Here again, we have the freedom to decide that I chose the > scope wrongly and that this is therefore not shippable as is, but I do > not think there is time to significantly expand the scope at this > point. > > I mostly get why specifying an index that doesn't exist as part of advice, alongside a target relation, produces "matched" along with "inapplicable" and "failed". INDEX_SCAN(f no_such_index) /* matched, inapplicable, failed */ But less understandable is why a failure to match a subplan-qualified target produces "matched" when the subplan doesn't appear. SEQ_SCAN(t1@minmax_1) /* matched, failed */ Maybe we need to do something like: relname - matches anywhere in the plan tree relname@somewhere - only looks at "somewhere" for matches; absence of somewhere results in "not matched" (the expected feedback for the advice/query combination above). This would necessitate needing some way to specify "top-level" after the "@" symbol - leaving it blank would suffice. I haven't worked through "directly at the named subplan" versus "the named subplan and any descendants"... If keeping the status quo the existing behavior should be documented. The existing wording for not matched; "or it may occur if the relevant portion of the query was not planned," seems to be the one that covers this case. David J.
