dsmiley commented on code in PR #2021:
URL: https://github.com/apache/solr/pull/2021#discussion_r1408490861
##########
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 suppose the current logic is trying to avoid this very call here --
`vinfo.lookupVersion` which probably isn't all that expensive in the context of
indexing a doc but it's something. It must get a "realTimeSearcher", which
usually can use the existing one (assume a sane commit strategy; not per doc).
It looks up the doc ID by a term dictionary lookup of the uniqueKey value, then
with that goes to resolve the version via numeric docValues retrieval (if the
doc actually exists, i.e. is an update).
I'm still +1 but just identifying trade-offs made in the past; perhaps
prematurely with a high complexity price.
And expect a follow-up PR from me to eliminate the "buckets" altogether :-)
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
