[
https://issues.apache.org/jira/browse/SOLR-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-5783:
---------------------------
Attachment: SOLR-5783.patch
Updated patch:
* hardend the modified assertion in TestIndexSearcher.testReopen to verify it
truly is the exact same searcher
* added a new TestSearcherReuse to verify that we get the same searcher after
doing various things that are No-Ops, and we get a new searcher after doing
things that modify the index.
still one nocommit: i want to make this use managed-schema and include a check
that modifing the schema w/o any data cahnges results in a newSearcher (need to
poke around the managed schema tests more to figure out how to do that)
> Can we stop opening a new searcher when the index hasn't changed?
> -----------------------------------------------------------------
>
> Key: SOLR-5783
> URL: https://issues.apache.org/jira/browse/SOLR-5783
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-5783.patch, SOLR-5783.patch, SOLR-5783.patch
>
>
> I've been thinking recently about how/when we re-open searchers -- and what
> the overhead of that is in terms of caches and what not -- even if the
> underlying index hasn't changed.
> The particular real world case that got me thinking about this recently is
> when a deleteByQuery gets forwarded to all shards in a collection, and then
> the subsequent (soft)Commit (either auto or explicit) opens a new searcher --
> even if that shard was completley uneffected by the delete.
> It got me wondering: why don't re-use the same searcher when the index is
> unchanged?
> From what I can tell, we're basically 99% of the way there (in
> {{<nrtMode/>}})...
> * IndexWriter.commit is already smart enough to short circut if there's
> nothing to commit
> * SolrCore.openNewSearcher already uses DirectoryReader.openIfChanged to see
> if the reader can be re-used.
> * for "realtime" purposes, SolrCore.openNewSearcher will return the existing
> searcher if it exists and the DirectoryReader hasn't changed
> ...The only reason I could think of for not _always_ re-using the same
> searcher when the underlying DirectoryReader is identical (ie: that last
> bullet above) is in the situation where the "live" schema has changed -- but
> that seems pretty trivial to account for.
> Is there any other reason why this wouldn't be a good idea for improving
> performance?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
