: Probably because the [NOW/DAYS-7DAYS+TO+NOW] part gets rewritten as lots : of OR clauses. I think that you'll see that if you add &debugQuery=true : to the URL. Make sure your recorded_date_dt is not too granular (e.g. : if you don't need minutes, round the values to hours. If you don't need : hours, round the values to days).
for the record: it doesn't get rewritten to a lot of OR clauses, it's using ConstantScoreRangeQuery. granularity is definitely important however, bth when indexing and when querying. "NOW" is milliseconds, so every time you execute that query it's different and there is almost no caching possible. if you use [NOW/DAY-7DAYS TO NOW/DAY] or even [NOW/DAY-7DAYS TO NOW/HOUR] you'll get a lot better caching behavior. it looks like you are trying to find anything in the past week, so you may want [NOW/DAY-7DAYS TO NOW/DAY+1DAY] (to go to the end of the current day) once you have a less granular date restriction, it can frequently make sense to put this in a seperate fq clause, so it will get cached independently of your main query. But Otis's point about reducing granularity can also help when indexing ... the fewer "unique" dates that apepar in your index, the faster range queries will be ... if you've got 1000 documents that all of a recordeddate of June 11 2008, but at different times, and you're never going to care aboutthe times (just the date) then strip those times off when indexing so they all have the same fieled value of 2008-06-11T00:00:00Z BTW: the solr port you sent out a URL to ... all of it's caching is turned off (the filterCache and queryResultCache configs are commented out of your solrconfig.xml) ... you're going to wnat to turn on some caching or you'll never see really *great* request times. -Hoss
