[multistage] Replace LogicalTableScan with PinotLogicalTableScan #15225
Conversation
ankitsultana
added
multi-stage
| + " {\n" | ||
| + " \"id\": \"0\",\n" | ||
| + " \"relOp\": \"LogicalTableScan\",\n" | ||
| + " \"relOp\": \"org.apache.pinot.calcite.rel.logical.PinotLogicalTableScan\",\n" |
There was a problem hiding this comment.
These are required because RelJson only converts to short names for calcite specific packages.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #15225 +/- ##
============================================
+ Coverage 61.75% 63.66% +1.90%
- Complexity 207 1461 +1254
============================================
Files 2436 2774 +338
Lines 133233 156264 +23031
Branches 20636 23983 +3347
============================================
+ Hits 82274 99478 +17204
- Misses 44911 49299 +4388
- Partials 6048 7487 +1439
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
...-query-planner/src/main/java/org/apache/pinot/calcite/rel/logical/PinotLogicalTableScan.java
Outdated
Show resolved
Hide resolved
| public static PinotImplicitTableHintRule withWorkerManager(WorkerManager workerManager) { | ||
| return new PinotImplicitTableHintRule(ImmutablePinotImplicitTableHintRule.Config.builder() | ||
| .operandSupplier(b0 -> b0.operand(LogicalTableScan.class).anyInputs()) | ||
| .operandSupplier(b0 -> b0.operand(PinotLogicalTableScan.class).anyInputs()) |
There was a problem hiding this comment.
Given that we are changing this now, don't you think we should be using the generic TableScan here? Is there a reason we can only apply this (and other) rule to Logical tables?
There was a problem hiding this comment.
Yeah using TableScan here would be better since this rule is not dependent on either Logical table scan or the new Pinot named variant. Updated.
| if (tableScan instanceof LogicalTableScan) { | ||
| call.transformTo(PinotLogicalTableScan.create(call.rel(0))); | ||
| } else if (!(tableScan instanceof PinotLogicalTableScan)) { | ||
| throw new IllegalStateException("Unknown table scan in PinotTableScanConverterRule: " + tableScan.getClass()); |
There was a problem hiding this comment.
Can we use a QueryException here instead?
There was a problem hiding this comment.
The thrown exception here would get caught in MultiStageBrokerRequestHandler which will set the QUERY_PLANNING_ERROR_CODE. I think the idea behind this approach is that the planner etc. can throw whatever exception seems right in their context (e.g. illegal state in this case), and the broker request handler will convert it to a structured form with an error code.
I don't think QueryException is used for throwing. It is mainly used for getting a ProcessingException which shows up nicely in broker response (we should ideally make the contract explicit in QueryException javadocs)
There was a problem hiding this comment.
That has recently changed in #15037. Now QueryException is an actual exception. The idea is that you can throw it anywhere during query processing and that way you can define the QueryErrorCode being used. That is not 100% true because there are still some paths that haven't been updated, but it is pretty safe to think that way.
For example, here we know that the error is not related to the query but a bug in our code, so it could be marked as QueryErrorCode.INTERNAL instead of QueryErrorCode.QUERY_PLANNING.
Anyway, it is completely valid to delegate the caller's responsibility to catch the exception and set the error code.
There was a problem hiding this comment.
Ah damn saw this comment after merging. I am working on another PR.. can update this there. Thanks for sharing this. This looks like a better approach to me.
There was a problem hiding this comment.
On line 34, you can directly match LogicalTableScan. I don't think we need to protect it from getting a different TableScan node
4 participants
LogicalTableScandrops traits in thecopymethod, and the copy method is used often during calcite planning to copy theRelNodein a type agnostic manner.Hence introducing a new node for this.