On Wed, Mar 4, 2026 at 5:04 PM Robert Haas <[email protected]> wrote: > Here's v57.
I've instrumented the length of the partial pathlist across all RelOptInfo objects in a run of the core regression test suite. Here's the result: without the patch: 1->9343 2->5859 3->38 with the v57 patch: 1->9306 2->5877 3->51 4->4 5->2 That seems very reasonable to me. It means that, across the test suite, we retain 0.3% more paths than before, and the percentage of partial pathlists of length 1 drops from 61.31% to 61.06%. That is a very modest impact, and it has the upside that in some cases we might get better plans, which is worth a lot. In fact, looking through the regression test changes in the patch, the changes to incremental_sort.out look like improvements: in the first hunk, we now push a PartialAggregate beneath Gather Merge, allowing more work to be done in parallel. In the second hunk, we now put the cheaper scan on the inner side of a Parallel Hash Join instead of the more expensive one. Since the inner side is the build table, the total cost of that side becomes startup cost for hash join, so this change is theoretically better. The total cost of the Parallel Hash Join remains unchanged, while its startup cost drops from 612.32 to 264.32. In this instance, that doesn't improve the startup or total cost for the plan as a whole, but I believe that's just a consequence of the fact that this particular query happens to be putting all of the rows into a single group. In other cases, it might help. The case in join_hash.out is similar: it's testing a join between two tables which, at present, are exactly the same, so even the tiniest perturbation in the costing formulas can upset the plan and cause it not to test the right thing any more. In the patch, I change it so that one side of the join has 2 rows and the other side has 3 rows, and it then puts the 2-row side on the inner side of the parallel hash join for the same reasons discussed in the previous paragraph. This should work just as before but be more stable with these changes. I feel like I've done all the due diligence that I can think of here to be sure that this is correct and doesn't cause a path explosion or plan regressions, so I plan to go ahead and commit this unless there are objections RSN. Thanks, -- Robert Haas EDB: http://www.enterprisedb.com
