You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2017/04/21 22:38:04 UTC
[jira] [Updated] (PHOENIX-3805) Generate index updates directly for
partial index rebuild on failure
[ https://issues.apache.org/jira/browse/PHOENIX-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Taylor updated PHOENIX-3805:
----------------------------------
Description:
We currently reissue data table updates to force the index rows to be generated. Instead, we should generate the index updates directly. The easiest, smaller optimization would be to abort the write of the data table row (in our Indexer coprocessor, based on some new state passed through), but still go through the standard code path of issuing the mutations to the data table. A more ambitious approach would be to figure out the updates to the indexes directly, instead of going through the code path of updating the data rows. This would be more work and would assume that out-of-order rows would not occur during a partial index rebuild (and hence we wouldn't need the row lock that's in place automatically when going through the data table write path).
This code is in UngroupedAggregateRegionObserver.rebuildIndices().
was:We currently reissue data table updates to force the index rows to be generated. Instead, we should generate the index updates directly. This code is in UngroupedAggregateRegionObserver.rebuildIndices().
> Generate index updates directly for partial index rebuild on failure
> --------------------------------------------------------------------
>
> Key: PHOENIX-3805
> URL: https://issues.apache.org/jira/browse/PHOENIX-3805
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> We currently reissue data table updates to force the index rows to be generated. Instead, we should generate the index updates directly. The easiest, smaller optimization would be to abort the write of the data table row (in our Indexer coprocessor, based on some new state passed through), but still go through the standard code path of issuing the mutations to the data table. A more ambitious approach would be to figure out the updates to the indexes directly, instead of going through the code path of updating the data rows. This would be more work and would assume that out-of-order rows would not occur during a partial index rebuild (and hence we wouldn't need the row lock that's in place automatically when going through the data table write path).
> This code is in UngroupedAggregateRegionObserver.rebuildIndices().
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)