The performance of NumericRangeQuery is much better
than the corresponding TermRangeQuery because the
number of terms that must be searched is usually far
fewer, thanks to trie indexing, described below.

You can optionally specify a precisionStep
when creating this query. This is necessary if you've
changed this configuration from its default (4) during
indexing. Lower values consume more disk space but speed
up searching. Suitable values are between 1 and
8. A good starting point to test is 4,
which is the default value for all Numeric*
classes. See below for
details.

A quote from this paper: Because Apache Lucene is a full-text
search engine and not a conventional database, it cannot handle numerical ranges
(e.g., field value is inside user defined bounds, even dates are numerical values).
We have developed an extension to Apache Lucene that stores
the numerical values in a special string-encoded format with variable precision
(all numerical values like doubles, longs, floats, and ints are converted to
lexicographic sortable string representations and stored with different precisions
(for a more detailed description of how the values are stored,
see NumericUtils). A range is then divided recursively into multiple intervals for searching:
The center of the range is searched only with the lowest possible precision in the trie,
while the boundaries are matched more exactly. This reduces the number of terms dramatically.

For the variant that stores long values in 8 different precisions (each reduced by 8 bits) that
uses a lowest precision of 1 byte, the index contains only a maximum of 256 distinct values in the
lowest precision. Overall, a range could consist of a theoretical maximum of
7*255*2 + 255 = 3825 distinct terms (when there is a term for every distinct value of an
8-byte-number in the index and the range covers almost all of them; a maximum of 255 distinct values is used
because it would always be possible to reduce the full 256 values to one term with degraded precision).
In practice, we have seen up to 300 terms in most cases (index with 500,000 metadata records
and a uniform value distribution).

Steps ≥64 for long/double and ≥32 for int/float produces one token
per value in the index and querying is as slow as a conventional TermRangeQuery. But it can be used
to produce fields, that are solely used for sorting (in this case simply use Integer.MAX_VALUE as
precisionStep). Using IntField,
LongField, FloatField or DoubleField for sorting
is ideal, because building the field cache is much faster than with text-only numbers.
These fields have one term per value and therefore also work with term enumeration for building distinct lists
(e.g. facets / preselected values to search for).
Sorting is also possible with range query optimized fields using one of the above precisionSteps.

Comparisons of the different types of RangeQueries on an index with about 500,000 docs showed
that TermRangeQuery in boolean rewrite mode (with raised BooleanQuery clause count)
took about 30-40 secs to complete, TermRangeQuery in constant score filter rewrite mode took 5 secs
and executing this class took <100ms to complete (on an Opteron64 machine, Java 1.5, 8 bit
precision step). This query type was developed for a geographic portal, where the performance for
e.g. bounding boxes or exact date/time stamps is important.

Method Detail

newLongRange

Factory that creates a NumericRangeQuery, that queries a long
range using the given precisionStep.
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

newLongRange

Factory that creates a NumericRangeQuery, that queries a long
range using the default precisionStepNumericUtils.PRECISION_STEP_DEFAULT (4).
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

newIntRange

Factory that creates a NumericRangeQuery, that queries a int
range using the given precisionStep.
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

newIntRange

Factory that creates a NumericRangeQuery, that queries a int
range using the default precisionStepNumericUtils.PRECISION_STEP_DEFAULT (4).
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

newDoubleRange

Factory that creates a NumericRangeQuery, that queries a double
range using the given precisionStep.
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null.
Double.NaN will never match a half-open range, to hit NaN use a query
with min == max == Double.NaN. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

newDoubleRange

Factory that creates a NumericRangeQuery, that queries a double
range using the default precisionStepNumericUtils.PRECISION_STEP_DEFAULT (4).
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null.
Double.NaN will never match a half-open range, to hit NaN use a query
with min == max == Double.NaN. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

newFloatRange

Factory that creates a NumericRangeQuery, that queries a float
range using the given precisionStep.
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null.
Float.NaN will never match a half-open range, to hit NaN use a query
with min == max == Float.NaN. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

newFloatRange

Factory that creates a NumericRangeQuery, that queries a float
range using the default precisionStepNumericUtils.PRECISION_STEP_DEFAULT (4).
You can have half-open ranges (which are in fact </≤ or >/≥ queries)
by setting the min or max value to null.
Float.NaN will never match a half-open range, to hit NaN use a query
with min == max == Float.NaN. By setting inclusive to false, it will
match all documents excluding the bounds, with inclusive on, the boundaries are hits, too.

getTermsEnum

Construct the enumeration to be used, expanding the
pattern term. This method should only be called if
the field exists (ie, implementations can assume the
field does exist). This method should not return null
(should instead return TermsEnum.EMPTY if no
terms match). The TermsEnum must already be
positioned to the first matching term.
The given AttributeSource is passed by the MultiTermQuery.RewriteMethod to
provide attributes, the rewrite method uses to inform about e.g. maximum competitive boosts.
This is currently only used by TopTermsRewrite