[ 
https://issues.apache.org/jira/browse/SOLR-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249639#comment-14249639
 ] 

Per Steffensen commented on SOLR-6816:
--------------------------------------

I believe today overwrite=false will not prevent neither document-version-check 
on leader (it will in the Solr we use in my company, but not in Apache Solr) 
nor bucket-version-check on non-leaders. As far as I can see 
{{DistributedUpdateProcessor.versionAdd}} will do document-version-check if 
versionsStored=true, leaderLogic=true and versionOnUpdate != 0. It will do 
bucket-version-check if versionsStored=true and leaderLogic=false. This has 
nothing to do with overwrite param. This version-check is not only for 
add-commands but also for delete-commands.

The overwrite param controls only (in {{DirectUpdateHandler2}}) if you make 
sure to delete an existing document with the same id, before you add the new 
document. You do that by default, but if overwrite=false you just add the new 
document, allowing duplicates (defined to be documents that have the same 
id-value).

So as far as I read the code, document-version-check will only be performed on 
leaders. Non-leaders will only do bucket-version-check, and I do not think that 
is expensive?
As I said our version of Solr does not do document-version-check if 
overwrite=false. I think you should introduce that as well. But besides that, 
whats left to do in this area?

What did I not understand?

> Review SolrCloud Indexing Performance.
> --------------------------------------
>
>                 Key: SOLR-6816
>                 URL: https://issues.apache.org/jira/browse/SOLR-6816
>             Project: Solr
>          Issue Type: Task
>          Components: SolrCloud
>            Reporter: Mark Miller
>            Priority: Critical
>         Attachments: SolrBench.pdf
>
>
> We have never really focused on indexing performance, just correctness and 
> low hanging fruit. We need to vet the performance and try to address any 
> holes.
> Note: A common report is that adding any replication is very slow.



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

Reply via email to