We have implemented the suggested reduction in granularity by dropping
time altogether and simply disallowing time filtering. This, in light
of other search filters we have provided, should prove be sufficient
for our user base.
We did keep the fine granularity field not for filtering, but for
sorting. We definitely need the log entries to be presented in
chronological order, so the finer resolution date field is useful for
that at least.
Thanks for the detailed response.
Alok
On Oct 31, 2008, at 2:16 PM, Chris Hostetter wrote:
: 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
