This might be useful: http://searchhub.org/2012/02/23/date-math-now-and-filter-queries/
Best, Erick On Mon, May 19, 2014 at 12:09 AM, Dmitry Kan <solrexp...@gmail.com> wrote: > Thanks, Jack, Alex and Shawn. > > This makes proper sense. One win of rounding down on indexing side is > saving index space, according to hoss (reply over IRC): > > "with the TrieDateFields, rounding dates at indexing time won't have any > effect on the cachability of the rounded queries, and even for non cached > queries it shouldn't affect the performance much -- but yes, it would help > reduce index size" > > I haven't tried it myself, just thought to ask if somebody tried it already. > > Dmitry > > > On Sat, May 17, 2014 at 8:37 AM, Shawn Heisey <s...@elyograg.org> wrote: > >> On 5/15/2014 1:34 AM, Alexandre Rafalovitch wrote: >> > I thought the date math rounding was for _caching_ the repeated >> > queries, not so much the speed of the query itself. >> >> Absolutely correct. When NOW is used without rounding, caching is >> completely ineffective. This is because if the same query using NOW is >> sent multiple times several seconds apart, every one of those queries >> will be different after they are parsed and NOW is converted to an >> actual timestamp. >> >> > Also, if you are using TrieDateField, precisionStep value is how >> > optimization is done. There is bucketing at different level of >> > precision, so the range search works at the least granular level >> > first, etc. >> >> Some nitty-gritty details of how range queries are accelerated with the >> Trie data types and precisionStep are described in the Javadoc for >> NumericRangeQuery: >> >> >> http://lucene.apache.org/core/4_8_0/core/org/apache/lucene/search/NumericRangeQuery.html >> >> Thanks, >> Shawn >> >> > > > -- > Dmitry Kan > Blog: http://dmitrykan.blogspot.com > Twitter: http://twitter.com/dmitrykan
