If this date range is pretty static, you could (in Lucene's CVS codebase) wrap the DateFilter with a CachingWrappingFilter. Or you could construct a long-lived instance of an equivalent QueryFilter and reuse it across multiple queries. You would likely see dramatic differences using either of these approaches.
I did some timing tests and it looks like time is spent in the actual query rather than in creating the filter object. This seems to contradict your suggestion here, or am I misunderstanding how filters work?
Creating the filter object is not expensive... it's when it's used in the IndexSearcher.search method (i.e. when the bitset method is called) that the expense of term enumeration occurs. DateFilter does not cache it's bitset though, so if you are reusing the same DateFilter over and over you will incur that expense every time. CachingWrappingFilter, though, will cache the enumerated bitset and using the same instance again will not incur that expense of enumerating terms.
Make sense? So maybe the timing tests you were doing were timing the DateFilter as well.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
