lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Potter (JIRA)" <>
Subject [jira] [Commented] (SOLR-7332) Seed version buckets with max version from index
Date Tue, 07 Apr 2015 15:04:12 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message