[
https://issues.apache.org/jira/browse/PHOENIX-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajeshbabu Chintaguntla updated PHOENIX-2628:
---------------------------------------------
Attachment: PHOENIX-2628_v8.patch
[~jamestaylor]
bq. We'll need someone like Andrew Purtell to review and bless
IndexHalfStoreFileReader and IndexHalfStoreFileReaderGenerator. For example, is
it copacetic to derive from StoreFile.Reader? Are public and/or evolving APIs
being used exclusively? If not, we'll need to come to an agreement/plan with
the HBase community for ones that aren't. It'd be a shame to do all this work
and end up in the same place we're in now.
IndexHalfStoreFileReaderGenerator is using the coprocessor hooks and not using
any private APIs so having it is not a problem. IndexHalfStoreFileScanner
implementing private APIs of HFileScanner. In the current patch removed the
implementing HFileScanner and moved the logic of handling references to
StoreFileScanner implementation which has COPROCESSOR limited scope.
bq. For an aggregate query that is grouping on a subset of the leading PK
columns, we're not holding the region lock for the entire scan. This would be
similar to the above situation, I believe.
Will check this in other issue and I think this issue can happen for scanning
data table as well. I have fixed couple of issues earlier in this case.
bq. Is that correct and if so, is that because a split that occurs in the first
scan is already handled correctly? Can a split occur while iterating through
the rows from the first scan and if not, why not?
There is a chance that split can happen when scan in the middle or before
creating scanners for the new chunk. In the patch handling both the cases.
bq. Wouldn't it be simpler/better to just support this new local indexing for
the above versions and simplify the implementation? Or is there some case where
the StaleRegionBoundaryCacheException is being handled on the client-side that
I'm not seeing?
This issue is going to be same in new implementation and it should be handled.
So first we can commit this.
bq. This can be simpler, no? ScanUtil.isLocalIndex(scan)?true:false
Done. Just passing true to handle SRBE in all cases.
bq. For the new TableResultIterator constructor, if you're including the
QueryPlan as an argument, then you can likely remove the TableRef argument and
get it from the QueryPlan instead.
Removed tableRef parameter.
bq. For the new QueryPlan method, instead of passing null through, why not pass
context.getScan() here:
Done.
[~anoop.hbase] [~ramkrishna] [~enis] can you please review especially new
LocalIndexStoreFileScanner.
> Ensure split when iterating through results handled correctly
> -------------------------------------------------------------
>
> Key: PHOENIX-2628
> URL: https://issues.apache.org/jira/browse/PHOENIX-2628
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Rajeshbabu Chintaguntla
> Attachments: PHOENIX-2628-wip.patch, PHOENIX-2628.patch,
> PHOENIX-2628_v7.patch, PHOENIX-2628_v8.patch
>
>
> We should start with a test case to ensure this works correctly, both for
> scans and aggregates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
