Class ViewCompaction
ViewResolver into the form expected by the rest
of the query pipeline. The work is split into two phases so that ViewShadowRelation
siblings (CPS lenient lookups) survive long enough to be paired with their strict
UnresolvedRelation sibling at field-caps time:
preIndexResolution(LogicalPlan)— runs fromEsqlSessionbeforePreAnalyzer. Reshapes user-writtenSubquery/UnionAllstructures intoViewUnionAllso the analyzer sees a uniform tree shape. Leaves shadows in place; leaves nestedViewUnionAlls nested. TheUnresolvedRelationindex patterns it leaves in the tree are exactly whatPreAnalyzerhands to field-caps and whatResolveTablelater looks up.postIndexResolution(LogicalPlan)— runs as an analyzer rule afterResolveTable. Strips anyViewShadowRelationthat lenient field-caps did not fold into a siblingEsRelation(in Phase A this is all of them, since lenient field-caps is not yet wired up — see esql-planning#543), then flattens nestedViewUnionAlls and unwraps remainingNamedSubquerywrappers.
The split is what lets a colleague implement lenient field-caps purely as a Phase B analyzer
rule that lives between ResolveTable and postIndexResolution(org.elasticsearch.xpack.esql.plan.logical.LogicalPlan): shadows that match
remote indices get rewritten to UnresolvedRelation/EsRelation; shadows that
fail to match are simply left unresolved and postIndexResolution(org.elasticsearch.xpack.esql.plan.logical.LogicalPlan) sweeps them away. Ordering
details: see esql-planning#472.
Note: a small amount of compaction stays inside ViewResolver.buildPlanFromBranches(org.elasticsearch.xpack.esql.plan.logical.UnresolvedRelation, java.util.List<org.elasticsearch.xpack.esql.view.ViewResolver.ViewPlan>, int) —
specifically the per-level sibling UnresolvedRelation merge — to keep the resolved tree
compact at the per-level boundary, so wide branching levels of compactable views (e.g.
FROM v1, v2, ... v9) collapse to a single UnresolvedRelation rather than
tripping Fork.MAX_BRANCHES at post-analysis verification.
-
Field Summary
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionapply(LogicalPlan plan) Backward-compatible helper: runspreIndexResolution(LogicalPlan)followed bypostIndexResolution(LogicalPlan).static LogicalPlanPhase 2, runs as an analyzer rule afterResolveTable.static LogicalPlanPhase 1, runs beforePreAnalyzer.
-
Constructor Details
-
ViewCompaction
public ViewCompaction()
-
-
Method Details
-
apply
Backward-compatible helper: runspreIndexResolution(LogicalPlan)followed bypostIndexResolution(LogicalPlan). Production code calls the two phases separately; tests that exercise the compaction logic without going through the full analyzer call this to get the same end state as the live pipeline produces.- Specified by:
applyin classRule<LogicalPlan,LogicalPlan>
-
preIndexResolution
Phase 1, runs beforePreAnalyzer. Reshapes user-writtenSubquery/UnionAllstructures intoViewUnionAllfor uniform downstream handling. Deliberately does NOT stripViewShadowRelationsiblings or flatten nestedViewUnionAlls — those are deferred topostIndexResolution(org.elasticsearch.xpack.esql.plan.logical.LogicalPlan)so lenient field-caps (Phase B) can pair each shadow with its strict resolution at field-caps time. -
postIndexResolution
Phase 2, runs as an analyzer rule afterResolveTable. StripsViewShadowRelationsiblings that lenient field-caps did not resolve, then flattens nestedViewUnionAllstructures and unwraps remainingNamedSubquerywrappers. By the time this runs, all reachableUnresolvedRelations have been replaced byEsRelations, so theUnresolvedRelation-merge step insidecompactNestedViewUnionAlls(org.elasticsearch.xpack.esql.plan.logical.LogicalPlan)is effectively a no-op — siblingEsRelations stay separate (Strategy A from esql-planning#543).
-