[
https://issues.apache.org/jira/browse/PHOENIX-3824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16001541#comment-16001541
]
Vincent Poon commented on PHOENIX-3824:
---------------------------------------
[~lhofhansl] Yes it's a hot code path in that it's called anytime we want to
generate an index update. However the results are cached per mutation, so it's
only called once for a mutation with many versions.
It's not actually sorting. There's a call to guava's Ordering#min(), which
just does an O(N) comparison of cell lists. And for the comparison, I only
compare the last cell in each list, since it's assumed they're already ordered
from newest to oldest. So overall an O(N) operation where N is your number of
cell lists (families), not number of cells. If you have one family with a huge
number of cells it should return in constant time.
> Mutable Index partial rebuild adds more than one index row for updated data
> row
> -------------------------------------------------------------------------------
>
> Key: PHOENIX-3824
> URL: https://issues.apache.org/jira/browse/PHOENIX-3824
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.10.0
> Reporter: Vincent Poon
> Assignee: Vincent Poon
> Fix For: 4.11.0
>
> Attachments: PHOENIX-3824.v1.patch, PHOENIX-3824.v2.patch
>
>
> If you follow this sequence:
> 1) disable index
> 2) write an updates to a data table row
> 3) trigger the BuildIndexScheduleTask partial rebuild
> then you end up with two index rows for the one data table row.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
