IndexSearcher
Implements search over a single IndexReader.
Applications usually need only call the inherited .search method. For performance reasons, if your index is unchanging, you should share a single IndexSearcher instance across multiple searches instead of creating a new one per-search. If your index has changed and you wish to see the changes reflected in searching, you should use DirectoryReader.openIfChanged to obtain a new reader and then create a new IndexSearcher from that. Also, for low-latency turnaround it's best to use a near-real-time reader (DirectoryReader.open). Once you have a new IndexReader, it's relatively cheap to create a new IndexSearcher from it.
NOTE: The .search and .searchAfter methods are configured to only count top hits accurately up to 1,000 and may return a lower bound of the hit count if the hit count is greater than or equal to 1,000. On queries that match lots of documents, counting the number of hits may take much longer than computing the top hits so this trade-off allows to get some minimal information about the hit count without slowing down search too much. The TopDocs.scoreDocs array is always accurate however. If this behavior doesn't suit your needs, you should create collectorManagers manually with either [ ] or TopFieldCollectorManager and call .search.
NOTE: [ ] instances are completely thread safe, meaning multiple threads can call any of its methods, concurrently. If your application requires external synchronization, you should not synchronize on the IndexSearcher instance; use your own (non-Lucene) objects instead.
Types
Holds information about a specific leaf context and the corresponding range of doc ids to search within. Used to optionally search across partitions of the same segment concurrently.
A class holding a subset of the IndexSearchers leaf contexts to be executed within a single thread. A leaf slice holds references to one or more LeafReaderContextPartition instances. Each partition targets a specific doc id range of a LeafReaderContext.
Thrown when an attempt is made to add more than .getMaxClauseCount clauses. This typically happens if a PrefixQuery, FuzzyQuery, WildcardQuery, or TermRangeQuery is expanded to many terms during search.
Thrown when a client attempts to execute a Query that has more than .getMaxClauseCount total clauses cumulatively in all of its children.
Properties
Functions
Returns CollectionStatistics for a field, or null if the field does not exist (has no indexed terms)
Returns an Explanation that describes how doc scored against query.
Returns the TaskExecutor that this searcher relies on to execute concurrent operations
Finds the top n hits for query.
Lower-level search API.
Lower-level search API. Search all leaves using the given CollectorManager. In contrast to .search, this method will use the searcher's Executor in order to parallelize execution of the collection on the configured .getSlices.
Search implementation with arbitrary sorting.
Search implementation with arbitrary sorting, plus control over whether hit scores and max score should be computed. Finds the top n hits for query, and sorting the hits by the criteria in sort. If doDocScores is true then the score of each hit will be computed and returned. If doMaxScore is true then the maximum score over all collected hits will be computed.
Finds the top n hits for query where all results are after a previous result (after).
Finds the top n hits for query where all results are after a previous result (after), allowing control over whether hit scores and max score should be computed.
Returns a StoredFields reader for the stored fields of this index.
Returns TermStatistics for a term.