On Tue, Mar 3, 2026 at 11:11 PM David G. Johnston <[email protected]> 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 has in applying that advice. > Therefore, generated advice targets may later fail for no other reason than > cost-based decisions resulted in the originally chosen plan to no longer be > chosen. The planner will still likely see the original target on a now > losing plan and thus the advice feedback will report matched even when the > winning plan does not include the specific 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
