See also: https://issues.couchbase.com/browse/MB-21046
This reverts commit 6d6fae2895.
It turns out that boolean searcher was depending on its 'should'
constituent (a disjunction query) and its min state changes, so a
rewrite wasn't safe/correct given this situation.
On a dev laptop, bleve-query benchmark on wiki dataset using
query-string of "+text:afternoon +text:coffee" previously had
throughput of 1222qps, and with this change hits 1940qps.
This change to upside_down term-field-reader no longer moves the
underlying iterator forward preemptively. Instead, it will invoke
Next() on the underlying iterator only when the caller invokes the
term-field-reader's Next().
There's a special case to handle the situation on the first Next()
invocation after the term-field-reader is created.
On my dev laptop, the bleve-query benchmark of query-string
"+text:afternoon +text:coffee" (which gets parsed into a conjection of
disjunctions) had throughput of 308qps before this change, and after
this change was 342qps.
This change simplifies and removes the DisjunctionSearcher.currentID
tracking, and instead utilizes the the matching/matchingIdxs slices
for tracking the required information.
As the core of the optimization, the previous code used two loop
passses to compare the internal ID's to the currentID field. This
commit instead optimizes to have a single pass to both compare the
internalID's and to also maintain the matching/matchingIdxs arrays.
On my dev box, using a bleve-query benchmark on a wiki dataset, with
query-string of "text:afternoon text:coffee", the previous code had
throughput of 958qps, and this commit has 1174qps.
A common search case is when a user performs a query-string query,
such as for "the lazy dog". That would be parsed into a boolean query
with a nil Must child, a nil MustNot child, and a non-nil Should child
(a disjunction query for "the", "lazy", "dog").
The optimization in this case is to return just the Should child
directly, skipping any additional Must and MustNot overhead.
On a dev box bleve-query benchmark on a wiki index with a query string
of "text:afternoon text:coffee", the throughput was previously 873qps
and with this change hits 940qps.
Optimization for DisjunctionSearcher, where an extra matchingIdxs
helps track the currs that were matching. This avoids the previous
code's second loop through the currs slice.
This commit modifies the upside_down TermFrequencyRow parseKDoc() to
skip the ByteSeparator (0xFF) scan, as we already know the term's
length in the UpsideDownCouchTermFieldReader.
On my dev box, results from bleve-query test on high frequency terms
went from previous 107qps to 124qps.
The DumpXXX() methods were always documented as internal and
unsupported. However, now they are being removed from the
public top-level API. They are still available on the internal
IndexReader, which can be accessed using the Advanced() method.
The DocCount() and DumpXXX() methods on the internal index
have moved to the internal index reader, since they logically
operate on a snapshot of an index.
