lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Updated: (LUCENE-2669) NumericRangeQuery.NumericRangeTermsEnum sometimes seeks backwards
Date Sun, 26 Sep 2010 20:08:33 GMT


Uwe Schindler updated LUCENE-2669:

    Attachment: LUCENE-2669.patch

Here a patch that fixed NRTE to only seek forward. This should also improve NRQ's perf in

It works like the following:

# nextSeekTerm() checks that the next range already fits the *current* term. If not it forwards
to the next sub-range and returns a seek term that is at least greater or equal the *current*
# accept() checks for the non-hit case (seldom as for a NRQ most terms are hits until the
upper sub-range-bound is reached), if the next sub-range lower bound term on the stack is
greater that the *current* one, and only then returns NO_AND_SEEK. If this is not the case,
it does not seek but instead only move forward to the next sub-range and repeats the bounds
checks [for(;;) loop].

> NumericRangeQuery.NumericRangeTermsEnum sometimes seeks backwards
> -----------------------------------------------------------------
>                 Key: LUCENE-2669
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Michael McCandless
>            Assignee: Uwe Schindler
>             Fix For: 3.1, 4.0
>         Attachments: LUCENE-2669.patch, LUCENE-2669.patch
> Subclasses of FilteredTermsEnum are "supposed to" seek forwards only (this gives better
performance, typically).
> However, we don't check for this, so I added an assert to do that (while digging into
testing the SimpleText codec) and NumericRangeQuery trips the assert!
> Other MTQs seem not to trip it.
> I think I know what's happening -- say NRQ has term ranges a-c, e-f to seek to, but then
while it's .next()'ing through the first range, the first term after c is f.  At this point
NRQ sees the range a-c is done, and then tries to seek to term e which is before f.  Maybe
NRQ's accept method should detect this case (where you've accidentally .next()'d into or possibly
beyond the next one or more seek ranges)?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message