[Feature] Add Lance connector optimizer operators and rules#74660
[Feature] Add Lance connector optimizer operators and rules#74660beinan wants to merge 3 commits into
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 78e577bb81
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } else if (Table.TableType.LANCE.equals(node.getTable().getType())) { | ||
| scanOperator = new LogicalLanceScanOperator(node.getTable(), colRefToColumnMetaMapBuilder.build(), | ||
| columnMetaToColRefMap, Operator.DEFAULT_LIMIT, null); |
There was a problem hiding this comment.
Enable Lance tables before adding scan planning
This new Lance branch is unreachable for normal SQL queries because QueryAnalyzer only passes a TableRelation through when table.isSupported() is true, and LanceTable.isSupported() currently returns false; a SELECT from any Lance connector table is still rejected as Unsupported scan table type: LANCE before RelationTransformer can create this operator. The feature's optimizer plumbing therefore does not make Lance scans plannable unless the Lance table support gate is updated as part of the same change.
Useful? React with 👍 / 👎.
| public <R, C> R accept(OptExpressionVisitor<R, C> visitor, OptExpression optExpression, C context) { | ||
| return visitor.visitPhysicalLanceScan(optExpression, context); |
There was a problem hiding this comment.
Add a plan-fragment translator for Lance scans
Once a Lance scan reaches physical planning, this dispatch has no corresponding visitPhysicalLanceScan override in PlanFragmentBuilder.PhysicalPlanTranslator (unlike Kudu/Hive/Paimon/etc.). The base visitor routes visitPhysicalLanceScan to visitPhysicalScan, which calls the translator's overridden visit(...) and re-enters this accept(...) method, so any planned Lance scan recurses until a stack overflow instead of producing a ScanNode.
Useful? React with 👍 / 👎.
78e577b to
e8767ae
Compare
|
@github-actions run-checks |
e8767ae to
601ce03
Compare
Add the FE optimizer plumbing for the Lance connector: - LogicalLanceScanOperator / PhysicalLanceScanOperator with visitor hooks - LOGICAL_LANCE_SCAN / PHYSICAL_LANCE_SCAN enum entries in OperatorType - LanceScanImplementationRule + IMP_LANCE_LSCAN_TO_PSCAN rule type - Wire into RuleSet, PushDownPredicateScanRule, StatisticsCalculator, LogicalPlanPrinter, and RelationTransformer This follows the same pattern used by the Kudu connector. Signed-off-by: Beinan Wang <soros.wang@yahoo.com> Co-Authored-By: Beinan Wang <beinanwang@microsoft.com> Signed-off-by: Beinan Wang <soros.wang@yahoo.com>
601ce03 to
7de25df
Compare
|
@github-actions run-checks |
1 similar comment
|
@github-actions run-checks |
Signed-off-by: Beinan Wang <soros.wang@yahoo.com>
|
Hi @stephen-shelby @HangyuanLiu, gentle ping on this PR when you have a chance. It is the first (bottom) PR of the Lance connector stack (#74660 → #74661 → #74662 → #74663 → #74664) and only adds the optimizer operators/rules. CI is green except for a known flaky |
Cover LogicalLanceScanOperator, PhysicalLanceScanOperator, and LanceScanImplementationRule to satisfy FE incremental coverage. Signed-off-by: Beinan Wang <soros.wang@yahoo.com> Co-Authored-By: Beinan Wang <beinanwang@microsoft.com>
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 45 / 54 (83.33%) file detail
|
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
Why I'm doing this
The Lance connector needs FE optimizer support so that
SELECTqueries againstLance tables can be planned and optimized through the standard StarRocks
cost-based optimizer pipeline.
What I'm doing
Add the optimizer-layer plumbing for Lance, following the same pattern as the
existing Kudu connector:
LOGICAL_LANCE_SCANandPHYSICAL_LANCE_SCANinOperatorTypeLogicalLanceScanOperatorandPhysicalLanceScanOperatorvisitLogicalLanceScan/visitPhysicalLanceScaninOperatorVisitorandOptExpressionVisitorLanceScanImplementationRule+IMP_LANCE_LSCAN_TO_PSCANin
RuleTypeRuleSetimplementation rules listLOGICAL_LANCE_SCANadded toPushDownPredicateScanRuleStatisticsCalculatorcomputes stats viaMetadataMgrLogicalPlanPrinterprints "LANCE SCAN"RelationTransformercreatesLogicalLanceScanOperatorfor
LANCEtable typeDoes this PR entail a change in behavior?
If yes, please specify the type of change:
Related Issue
Fixes #74665