[
https://issues.apache.org/jira/browse/PHOENIX-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14063182#comment-14063182
]
Gabriel Reid commented on PHOENIX-539:
--------------------------------------
Just catching back up with this stuff now -- ok, that explanation on the
multiple repeating keys makes sense.
I can take a look at making the ChunkedResultIterator only stop after a row key
change. I think that this same issue could also come up if we would be somehow
returning multiple versions of the same row, as the current logic is dependent
on a single row key only being present once.
The one problem I'm thinking that there could be is that in order to stop a
chunk between two different keys, the next key needs to be read (and then
discarded), which seems pretty unfortunate. I'll take a look to see if I can
find a way to get around this, but any ideas on a clever (or not so clever) way
to get around that are welcome.
> 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)
