diff --git a/src/java/org/apache/lucene/document/NumericField.java b/src/java/org/apache/lucene/document/NumericField.java
index 6890b07e814..56eadd79226 100644
--- a/src/java/org/apache/lucene/document/NumericField.java
+++ b/src/java/org/apache/lucene/document/NumericField.java
@@ -107,6 +107,10 @@ import org.apache.lucene.search.FieldCache; // javadocs
* like to change the value. Note that you must also
* specify a congruent value when creating {@link
* NumericRangeQuery} or {@link NumericRangeFilter}.
+ * For low cardinality fields larger precision steps are good.
+ * If the cardinality is < 100, it is fair
+ * to use {@link Integer#MAX_VALUE}, which produces one
+ * term per value.
*
*
For more information on the internals of numeric trie
* indexing, including the The default for all data types is 4, which is used, when no precisionStep
is given.
* Ideal value in most cases for 64 bit data types (long, double) is 6 or 8.
* Ideal value in most cases for 32 bit data types (int, float) is 4.
+ * For low cardinality fields larger precision steps are good. If the cardinality is < 100, it is
+ * fair to use {@link Integer#MAX_VALUE} (see below).
* 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 {@link TermRangeQuery}. But it can be used
* to produce fields, that are solely used for sorting (in this case simply use {@link Integer#MAX_VALUE} as
* precisionStep
). Using {@link NumericField NumericFields} 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
.
*
*