Re: [PROPOSAL] Expand OR clauses in joins to UNION ALL paths

On 27/10/2026 23:30, Zsolt Parragi wrote:
> Hello! v5 fails the basic test suite for me in an assert enabled build
Apologies, i had inadvertently run the previous test cycle on a build
without asserts and all TAP tests.

The assertion failure tripped at:

TRAP: failed Assert("list_length(dest_tlist) ==
list_length(src_tlist)"), File: "tlist.c", Line: 332
This occurred in queries with upper operations (aggregates, COUNT(*), or
GROUP BY) atop an OR-expanded join. while or_expansion_align_path()
projected the subpath to match the joinrel's targetlist,
arm->subroot->processed_tlist still retained the upper query's
targetlist. so the mismatch between the subplan's targetlist and
subroot->processed_tlist triggered the assert.

The fix for v5 is  just to synchronize the subroot's targetlist right
after alignment:

+   /* Synchronize subroot tlist with the arm's actual output target */
+   arm->subroot->processed_tlist =
+  arm->subroot->parse->targetList =
+  make_tlist_from_pathtarget(aligned->pathtarget);
With this fix in place, all assertion checks pass. I have attached a
fixed v5.

Later i found something else with pg_plan_advice story ; so v5 still
fails in one test here:

In v5, create_append_path() passed joinrel as the parent. Consequently,
Append.apprelids contained the join's base relations (e.g., {a, b} or
{generate_series, b}). This caused two problems for plan inspection:

So this is the reason we see Partitionwise, if the transformation was
doing something clean like an upper UNION ALL query with subqueries as
relids, it would have the same rtekind for each branch and would be a
normal Append from pg_plan_advice's perspective.
E.g: joining a table with a function scan or VALUES (e.g.,
generate_series(1, 4) g, table b WHERE g = b.x OR g = b.y),
pg_plan_advice threw:
ERROR: rtekind mismatch: 3 vs. 0

And as mentioned, an equivalent manual UNION ALL query does not suffer
from this, because a manual UNION ALL Append has an apprelids consisting
of just subquery RTIs (RTE_SUBQUERY).

So i thought of doing Set-Operation for AppendPath.

Instead of creating the AppendPath with joinrel as its parent, we build
it on an UPPERREL_SETOP upper relation keyed by the candidate arm
subqueries' RTIs, and then add it to joinrel->pathlist:

Now i'm not sure whether this is fine to do or not, especially given
that this kind of transformations has never been done in any other place
and this comes at an intermediate state of planning. At this point any
issue with pg_plan_advice is gone, because the patch has a more
standard-ish planning state than before.

what do you think ?

Regards,
Ayoub