On 12/14/2012 4:15 PM, Jack Krupansky wrote:
And the "official" answer when I posed the question on the Lucene User
list is that the time of day bits would still be stored in the index
in spite of the precisionStep. So, it doesn't really matter very much
at all what precisionStep you use for trie date fields..
As I understand it, the precisionStep parameter is all about indexing
additional data (taking more memory and disk space) in order to give a
major speed boost to range queries and date faceting.
More info:
http://lucene.apache.org/core/4_0_0/core/org/apache/lucene/search/NumericRangeQuery.html#precisionStepDesc
It will not result in any rounding of the actual dates contained in your
index. Unless you have a special component or DIH transformer, you'd
have to do any rounding before the data made it to Solr's update handler.
The default precisionStep value for the tdate fieldType in the example
schema is 6. TrieDateField is a 64-bit data type. For contrast, the
default precisionStep for tlong, another 64-bit value, is 8.
My guess is that unless you expect to have a very low number of unique
values in your tdate field, that you'll want to just leave it at the
default of 6. Usually a date field, especially one accurate to
millseconds like TrieDateField, ends up with a lot of unique values. If
your data source is only accurate to one second, it might be a good idea
to bump the precisionStep a little, perhaps 8-10. If the data source is
less accurate than that, you can make it even higher. Finding the
optimum value would require rigorous performance testing.
Thanks,
Shawn
