You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Maryann Xue (JIRA)" <ji...@apache.org> on 2016/09/14 21:56:20 UTC
[jira] [Created] (PHOENIX-3279)
QueryPlan.iterator(ParallelScanGrouper scanGrouper) should pass null
('unknown') as scan parameter when calling
this.iterator(ParallelScanGrouper scanGrouper, Scan scan)
Maryann Xue created PHOENIX-3279:
------------------------------------
Summary: QueryPlan.iterator(ParallelScanGrouper scanGrouper) should pass null ('unknown') as scan parameter when calling this.iterator(ParallelScanGrouper scanGrouper, Scan scan)
Key: PHOENIX-3279
URL: https://issues.apache.org/jira/browse/PHOENIX-3279
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.8.0
Reporter: Maryann Xue
Assignee: Maryann Xue
Fix For: 4.9.0
This issue was introduced by PHOENIX-2628, and it caused a regression in CalciteIT after calcite branch was synced with master branch.
In most implementations of QueryPlan.iterator(ParallelScanGrouper scanGrouper), the QueryPlan calls this.iterator(ParallelScanGrouper scanGrouper, Scan scan) with a Scan object it gets from its inner QueryPlan. This logic is actually wrong when a ScanPlan (or AggregatePlan) is nested in two or more DelegateQueryPlans. For example, TupleProjectionPlan(ClientScanPlan(ScanPlan), the TupleProjectionPlan will pass the ClientScanPlan.getContext().getScan() to ClientScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), and in turn to ScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), which will shadow the original Scan object in the ScanPlan.
It would be better to just pass "null" in indicate "unknown" in this case. The QueryPlan which does care about the Scan object, which is mostly BaseQueryPlan, will have to handle this "null" value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)