[
https://issues.apache.org/jira/browse/SOLR-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483321#comment-14483321
]
Timothy Potter commented on SOLR-7332:
--------------------------------------
bq. but why do we need to re-find the highest version here?
I was thinking that was safest to cover operations like merging indexes into
the current one but may be overkill ... I'll dig a little deeper into whether
that's really necessary because it'll be better if we don't have to re-fetch
the max after a reload.
bq. if those versions happened to be deletes
I'll need to think about this more too ... I thought I've seen something about
deletes having negative versions? Again, will dig deeper to understand this
better as version management around deletes is an area of weakness in my
understanding of the codebase.
bq. uploaded a version that should be faster
Thanks! That's cool code! I'll post back after I've dug deeper into ^^
> Seed version buckets with max version from index
> ------------------------------------------------
>
> Key: SOLR-7332
> URL: https://issues.apache.org/jira/browse/SOLR-7332
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Timothy Potter
> Assignee: Timothy Potter
> Attachments: SOLR-7332.patch, SOLR-7332.patch, SOLR-7332.patch,
> SOLR-7332.patch
>
>
> See full discussion with Yonik and I in SOLR-6816.
> The TL;DR of that discussion is that we should initialize highest for each
> version bucket to the MAX value of the {{__version__}} field in the index as
> early as possible, such as after the first soft- or hard- commit. This will
> ensure that bulk adds where the docs don't exist avoid an unnecessary lookup
> for a non-existent document in the index.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
