[
https://issues.apache.org/jira/browse/PHOENIX-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982729#comment-13982729
]
ASF GitHub Bot commented on PHOENIX-951:
----------------------------------------
Github user maryannxue commented on a diff in the pull request:
https://github.com/apache/incubator-phoenix/pull/32#discussion_r12034129
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/HashJoinRegionScanner.java
---
@@ -106,7 +113,7 @@ private void processResults(List<Cell> result, boolean
hasLimit) throws IOExcept
return;
}
- if (hasLimit)
+ if (hasBatchLimit)
throw new UnsupportedOperationException("Cannot support join
operations in scans with limit");
--- End diff --
This is actually to indicate if it is called from the "next" interface with
"limit" parameter, like "next(List<Cell> result, int limit)", and has nothing
to do with the SQL LIMIT clause. And that's why I renamed it "hasBatchLimit".
> Don't push LIMIT as PageFilter for joins
> ----------------------------------------
>
> Key: PHOENIX-951
> URL: https://issues.apache.org/jira/browse/PHOENIX-951
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 3.0.0, 4.0.0
> Reporter: James Taylor
> Assignee: Maryann Xue
> Priority: Minor
>
> When a join has a limit, you can't push the limit through a PageFilter since
> you might not get a match when you join the LHS to the RHS. I think ideally
> you'd want to push the LIMIT to the ScanRegionObserver (or
> GroupedAggregateRegionObserver) and then stop the inner scan when the limit
> is reached. There's a similar optimize for a GROUP BY that has a LIMIT with
> no ORDER BY.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
