Is your feature request related to a problem?
The current PPL Calcite V3 execution path and the Unified Query API contain overlapping responsibilities with duplicated code and divergent implementations. Over time, this increases maintenance cost and creates a growing risk of behavioral drift across PPL execution paths.
As the long-term PPL specification reference implementation, the Unified Query API should become the single entrypoint and reusable library for any PPL implementor or adopter, including OpenSearch itself.
What solution would you like?
Refactor the PPL Calcite V3 execution path to reuse the Unified Query API components as the primary building blocks:
- Unified Planning:
QueryService should delegate Calcite planning to UnifiedQueryPlanner instead of duplicating the AST-to-RelNode conversion and collation preservation logic.
- Unified Context:
QueryService should use UnifiedQueryContext (or share its context-building logic) instead of maintaining separate FrameworkConfig construction.
- Unified Execution:
OpenSearchExecutionEngine should leverage UnifiedQueryCompiler for plan compilation, or share a common execution abstraction.
As single source of truth, all Calcite-based execution flows (including UT/IT scaffolding and any shared base execution classes) should route through the same unified pipeline to ensure consistent behavior.
What alternatives have you considered?
- Keep separate implementations: Maintain both paths independently. This was rejected because it increases maintenance burden and risks behavioral divergence.
Do you have any additional context?
Current Architecture:
QueryService: UnresolvedPlan → CalcitePlanContext → CalciteRelNodeVisitor → RelNode
ExecutionEngine: RelNode → OpenSearchExecutionEngine.execute()
Target Architecture:
QueryService: UnresolvedPlan → UnifiedQueryPlanner → RelNode
ExecutionEngine: RelNode → UnifiedQueryCompiler → execute()
Is your feature request related to a problem?
The current PPL Calcite V3 execution path and the Unified Query API contain overlapping responsibilities with duplicated code and divergent implementations. Over time, this increases maintenance cost and creates a growing risk of behavioral drift across PPL execution paths.
As the long-term PPL specification reference implementation, the Unified Query API should become the single entrypoint and reusable library for any PPL implementor or adopter, including OpenSearch itself.
What solution would you like?
Refactor the PPL Calcite V3 execution path to reuse the Unified Query API components as the primary building blocks:
QueryServiceshould delegate Calcite planning toUnifiedQueryPlannerinstead of duplicating the AST-to-RelNode conversion and collation preservation logic.QueryServiceshould useUnifiedQueryContext(or share its context-building logic) instead of maintaining separateFrameworkConfigconstruction.OpenSearchExecutionEngineshould leverageUnifiedQueryCompilerfor plan compilation, or share a common execution abstraction.As single source of truth, all Calcite-based execution flows (including UT/IT scaffolding and any shared base execution classes) should route through the same unified pipeline to ensure consistent behavior.
What alternatives have you considered?
Do you have any additional context?
Current Architecture:
Target Architecture: