[
https://issues.apache.org/jira/browse/PHOENIX-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133631#comment-15133631
]
James Taylor commented on PHOENIX-2605:
---------------------------------------
Yes, but it's not for efficiency, but for correctness. The index population
does not do incremental maintenance. It only adds new index rows based on the
current rows in the data table. It doesn't remove the index row associated with
the old row. If the timestamp is not held back to a past time, then the index
population might be overwriting index rows that have subsequently been changed
by later updates to the data table.
If we're setting the timestamp back to the index creation time, but doing a
scan at a later time for the initial index population, that might be ok since
we're not supporting flashback queries for transactional tables. I can't come
up with a concrete example where this would cause a problem outside of
flashback queries. You'd potentially end up with two versions of an index row -
one with an earlier ts that was added by the initial index population and a
second one with a later ts that was added during incremental maintenance.
> Enhance IndexToolIT to test transactional tables
> ------------------------------------------------
>
> Key: PHOENIX-2605
> URL: https://issues.apache.org/jira/browse/PHOENIX-2605
> Project: Phoenix
> Issue Type: Test
> Reporter: Thomas D'Silva
> Assignee: Thomas D'Silva
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2605.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
