[
https://issues.apache.org/jira/browse/OAK-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722025#comment-15722025
]
Tommaso Teofili commented on OAK-5212:
--------------------------------------
right, but I think the {{DirectoryReader#listCommits}} is slightly more
expensive as it requires IO (read) on the {{Directory}} and therefore we need
to find out if in the end it's better to have slightly more IR openings and
saving some performance on each {{LuceneIndexWriter#close}} rather than a more
reliable policy which saves some IR openings but it's on average a bit more
expensive.
> Avoid updating the index nodestate if no change is done in index
> ----------------------------------------------------------------
>
> Key: OAK-5212
> URL: https://issues.apache.org/jira/browse/OAK-5212
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Priority: Minor
> Labels: performance
> Fix For: 1.6
>
> Attachments: OAK-5212-v1.patch
>
>
> As noted in OAK-5211 directory listing was getting modified (due to reorder)
> even if no change happens in index.
> Another place where we update state post index close is at ":status" node
> where we store {{lastUpdated}} and {{indexedNodes}} post index close. In
> normal cases LuceneIndexEditor avoids initializing the IndexWriter if there
> is no change. However it can happen that when any node gets deleted the
> editor performs a delete operation. It can happen that tree being deleted is
> not indexed but still editor would do this as it cannot determine that
> easily. And in doing that IndexWriter would be initialized.
> Currently IndexWriter being initialized is considered same as index updated.
> Due to this index status nodes gets unnecessarily updated even if there is no
> change in index which causes the IndexTracker to reopen the index even when
> it has not changed.
> We should make this more explicit and find a way to determine if index has
> been updated or not
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)