There is no quick answer, it really depends on a lot of factors... *TL;DR* : Updating a single document field will likely take more time in a bigger collection.
*Partial Document Update* First of all, which field are you updating ? Depending on the type and attributes you may end up in different scenarios[1]. For example, an in place update would be much more convenient and less expensive as it will not end up writing a new document in the index . Viceversa a normal atomic update will cause an internal delete/re-index of the doc. What happens next will depend on the commit policies ( or in case you saturated the internal ram buffer, the content of the segment will be flushed. *Solr Commit Policies* In Solr there is the concept of Soft and hard commit. A soft commit is cheaper : grants visibility, warms up the caches, does minimal ( potentially none) disk writing An hard commit will flush the current segment to the disk in addition ( which brings all the background operations that Emir pointed out). Help yourself with this Erick's great classic[2] *Warming the caches* will take more time in a bigger collection ( as the queries will be executed on a bigger index). *Merging the segments* in the background, if it's triggered will take more time in a bigger collection. [1] https://lucene.apache.org/solr/guide/6_6/updating-parts-of-documents.html#UpdatingPartsofDocuments-In-PlaceUpdates <https://lucene.apache.org/solr/guide/6_6/updating-parts-of-documents.html#UpdatingPartsofDocuments-In-PlaceUpdates> [2] understanding-transaction-logs-softcommit-and-commit-in-sorlcloud <https://lucidworks.com/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/> ----- --------------- Alessandro Benedetti Search Consultant, R&D Software Engineer, Director Sease Ltd. - www.sease.io -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
