For queryable encryption range-indexed fields having the type "double" or "decimal", the user may only either specify a min, max, and precision altogether, or leave them all unspecified. This means that if the user knows the upper and lower bounds of their data and wants to specify min and max, then they are also forced to specify a precision value. The precision parameter is mainly used by the OST algorithm to see if the range of values between min and max (up to that precision) can be re-encoded into fewer bits, so that there will be fewer hypergraph "edges" to index, hence incurring some performance benefits.

If the user chooses a precision that is too large for the given min..max range, then the optimization may not apply, and we just silently fall back to using the encoding that uses the full range of bits for that data type (i.e. 64 bits for double, 128 bits for decimal128), where min and max don't really serve any purpose performance-wise, except for bounds-checking.

According to the crypto team, it would be more helpful for users if there is an error (or at least a warning) stating that the precision they specified can't be used for the given min/max, instead of silently proceeding with the default encoding. For doubles, we can determine if the precision can't be applied if the formula log2((max - min + 1) * 10^precision) is greater than or equal to 64. For decimal, the precision can't be applied if the same formula results in a value greater than or equal to 128.