[
https://issues.apache.org/jira/browse/PHOENIX-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058830#comment-14058830
]
Maryann Xue commented on PHOENIX-539:
-------------------------------------
[~gabriel.reid], [~giacomotaylor], As I had a closer look at the code, I now
try to understand why it isn't doable with hash-join scan plans. Unlike
aggregate or order-by query, there is no correlation between different rows in
a hash-join scan (each row is joined against the hash table separately). The
only concern might be the hash cache live time, otherwise think the hash-join
scan could still work with the ChunkedResultIterator. Or maybe I missed
something here?
Also if this check were truly needed here, I realized that the change would be
a little trickier than simply moving the check into ScanPlan, so I'd do it if
necessary.
> Implement parallel scanner that does not spool to disk
> ------------------------------------------------------
>
> Key: PHOENIX-539
> URL: https://issues.apache.org/jira/browse/PHOENIX-539
> Project: Phoenix
> Issue Type: Task
> Reporter: James Taylor
> Assignee: Gabriel Reid
> Fix For: 5.0.0, 3.1, 4.1
>
> Attachments: PHOENIX-539.1.patch, PHOENIX-539.patch
>
>
> In scenarios where a LIMIT is not present on a non aggregate query that will
> return a lot of results, Phoenix spools the results to disk. This is less
> than ideal in these situations. @larsh has created a very good and relatively
> simple implementation that is queue based to replace this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
