[LUCENE-6032] Dealing with slow iterators

• Type: Wish
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Lucene Fields: New
• Assignee: Unassigned
• Reporter: Adrien Grand
• Created: 29/Oct/14 20:35
• Updated: 28/Aug/22 14:18
• Resolved: 16/Feb/15 18:14

Description

This is a recurring issue (for instance already discussed in LUCENE-5418) but queries can sometimes be super slow if they wrap a filter that provides linear-time nextDoc/advance.

LUCENE-5418 has the following comment:

New patch, throwing UOE from DocIdSet.iterator() for the Filter returned by Range.getFilter(). I like this approach: it's safer for the user so they don't accidentally apply a super slow filter.

I like this approach because doc id sets not providing efficient iteration should really be an exception rather than a common case. In addition, using an exception has the benefit of propagating the information through the call stack, which would not be the case if we used null or a sentinel value to say that the iterator is super slow. So if you write a filter that can wrap other filters and doesn't know how to deal with filters that don't support efficient iteration, you do not need to modify your code: it will work just fine with filters that support fast iteration and will fail on filters that don't.

Something I would like to explore is whether things like FilteredQuery could catch this exception in order to fall back automatically to a random-access strategy?

The general idea I have is that it is ok to apply a random filter as long as you have a fast iterator to drive iteration? So eg. a filtered query based on a slow iterator would make sense, but not a ConstantScoreQuery that would wrap a filter since it would need to evaluate the filter on all non-deleted documents (it would propagate the exception of the filter).

Issue Links

• is related to: LUCENE-6198 two phase intersection
• is superceded by: LUCENE-6198 two phase intersection