lucene-dev mailing list archives

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

     [ https://issues.apache.org/jira/browse/LUCENE-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

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
trunk.

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*
term
# 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: https://issues.apache.org/jira/browse/LUCENE-2669
>             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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message