: Concrete example, this query just look 18s: : : instance:client\-csm.symplicity.com AND dt:[2008-10-01T04:00:00Z TO : 2008-10-30T03:59:59Z] AND label_facet:"Added to Position"
: I saw a thread from Apr 2008 which explains the problem being due to too much : precision on the DateField type, and the range expansion leading to far too : many elements being checked. Proposed solution appears to be a hack where you : index date fields as strings and hacking together date functions to generate : proper queries/format results. forteh record, you don't need to index as a "StrField" to get this benefit, you can still index using DateField you just need to round your dates to some less graunlar level .. if you always want to round down, you don't even need to do the rounding yourself, just add "/SECOND" or "/MINUTE" or "/HOUR" to each of your dates before sending them to solr. (SOLR-741 proposes adding a config option to DateField to let this be done server side) your example query seems to be happy with hour resolution, but in theory if sometimes you needed hour resolution when doing "big ranges" but more precise resolution when doing "small ranges" you could even in theory have a "course" date field that you round to an hour, and redundently index the same data in a "fine" date field with minute or second resolution. Also: if you frequently reuse the same ranges over and over (ie: you have a form widget people pick from so on any given day there is only N discrete ranges being used) putting them in an "fq" param will let them be cached uniquely from the main query string (instance:client\-csm.symplicity.com) so differnet searches using the same date ranges will be faster. ditto for your label_facet:"Added to Position" clause. -Hoss
