On Tue, Mar 3, 2026 at 11:11 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> Ok, that’s what I was missing here, it saw the subplan in its options but the winning plan didn’t include it. So
“matched/failed”may produce a plan where the target having been matched isn’t actually visible to the user.
>
> Maybe add a note like this to pg_plan_advice:
>
> Generated advice is produced to a high level of specificity without knowing what limitations the advice interpreter
hasin applying that advice. Therefore, generated advice targets may later fail for no other reason than cost-based
decisionsresulted in the originally chosen plan to no longer be chosen. The planner will still likely see the original
targeton a now losing plan and thus the advice feedback will report matched even when the winning plan does not include
thespecific target.
There is doubtless lots of room for improvement in the documentation,
but this specific text doesn't seem like a good idea, because it's not
true in general. The whole point of test_plan_advice is to ensure that
generated advice targets *don't* fail, and with all the patches
applied, I get a clean run where every single advice target generated
by the main regression test suite can be successfully applied back to
the plan that generated it. I think the real issue here is that Jakub
has found a case where fiddling with the scan method causes the
optimal aggregation method to change, and the resulting weird behavior
stems from the fact that aggregation control is not supported. What
you want to be able to do is nail down the aggregation behavior first,
and then it would be clear whether to provide scan advice for t1 or
for t1@minmax_1.
But I just don't see what the big deal is here. One thing you can do
is provide advice for both t1 and t1@minmax_1 and then the advice will
be followed for whichever one appears in the final plan. The other
will be marked as failed, but you can decide to just ignore that.
Possibly you could even indirectly control whether the minmax path is
selected by advising an inefficient strategy for the one you don't
want to be be picked and a great strategy for the one you do want to
be picked. Also, I've personally never run into a real-world case
where the planner made a bad decision about whether to use a minmaxagg
or a regular agg, which is why all of my development time and effort
went into scans and joins and related topics where I do regularly see
things go wrong.
So at the risk of repeating myself: It is not in general true that you
should expect your advice to randomly not work, but that happens in
this case because aggregation control is not supported, which is a
documented limitation.
--
Robert Haas
EDB: http://www.enterprisedb.com
