bruno-roustant commented on code in PR #2021:
URL: https://github.com/apache/solr/pull/2021#discussion_r1408995357
##########
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java:
##########
@@ -507,29 +504,19 @@ private boolean doVersionAdd(
lastVersion);
return true;
} else {
- // We're good, we should apply this update. First, update the
bucket's highest.
- if (bucketVersion != 0 && bucketVersion < versionOnUpdate) {
- bucket.updateHighest(versionOnUpdate);
- }
+ // We're good, we should apply this update.
}
}
} else {
// if we aren't the leader, then we need to check that updates
were not re-ordered
- if (bucketVersion != 0 && bucketVersion < versionOnUpdate) {
- // we're OK... this update has a version higher than anything
we've seen
- // in this bucket so far, so we know that no reordering has yet
occurred.
- bucket.updateHighest(versionOnUpdate);
- } else {
- // there have been updates higher than the current update. we
need to check
- // the specific version for this id.
- Long lastVersion = vinfo.lookupVersion(cmd.getIndexedId());
Review Comment:
I agree this must have been the objective of the max version per bucket. I
also agree that, when the optimization triggers, it avoids the
vinfo.lookupVersion().
What I questioned is the frequency of when the optimization triggers, as it
occurs when the doc version is higher than the max version of all docs in the
bucket. That's why I ran multiple times the indexing benchmark to see if there
is a difference with and without the optimization.
My take on this is that the gain (apparently very low to none from the
benchmark) is not worth the complexity and the additional memory per Core.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
