[
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)
