RE: Date ranges - getting the approach right

6 July 2006 15:03 To: java-user@lucene.apache.org Subject: Re: Date ranges - getting the approach right Thanks for the clarification. Let me re-state this and see if I got it right. 1> if you never do any deletions (or recalculate your "special records" after deletion/optimization), this c

RE: Date ranges - getting the approach right

NetSearch -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: 16 July 2006 20:46 To: java-user@lucene.apache.org Subject: RE: Date ranges - getting the approach right : The second approach requires three hits, doesn't it? : : (1) TermQuery on start date + so

RE: Date ranges - getting the approach right

e if I can get good enough performance without it, though. -Original Message- From: Erick Erickson [mailto:[EMAIL PROTECTED] Sent: 16 July 2006 15:03 To: java-user@lucene.apache.org Subject: Re: Date ranges - getting the approach right Thanks for the clarification. Let me re-state this an

RE: Date ranges - getting the approach right

: The second approach requires three hits, doesn't it? : : (1) TermQuery on start date + sort on document ID : (2) TermQuery on end date + reverse sort on document ID : (3) The actual query with a filter on the above You wouldn't need 3 queries for each date range you wanted to precompute, you cou

RE: Date ranges - getting the approach right

ailto:[EMAIL PROTECTED] Sent: 16 July 2006 15:03 To: java-user@lucene.apache.org Subject: Re: Date ranges - getting the approach right Thanks for the clarification. Let me re-state this and see if I got it right. 1> if you never do any deletions (or recalculate your "special records&qu

Re: Date ranges - getting the approach right

Thanks for the clarification. Let me re-state this and see if I got it right. 1> if you never do any deletions (or recalculate your "special records" after deletion/optimization), this could work as-is. 2> the safe way to do this would be to find the miniminum doc ID for the start date, the maxi

Re: Date ranges - getting the approach right

On 7/15/06, Erick Erickson <[EMAIL PROTECTED]> wrote: I'm assuming that you only add to your index, and don't optimize it after deletions or do anything else that would change the document IDs That won't quite work... add() after delete() can change document ids because it can cause a segment m

Re: Date ranges - getting the approach right

Does it make any sense at all to pre-calculate and permanently store date range filters for each day? I'm assuming that you only add to your index, and don't optimize it after deletions or do anything else that would change the document IDs Lucene assigns AND you index each day's mail sequentially

RE: Date ranges - getting the approach right

34 To: java-user@lucene.apache.org Subject: Re: Date ranges - getting the approach right : I gather I should prefer RangeQuery to ConstantScoreQuery+RangeFilter, : because it is faster not to use a Filter. However, I sometimes have to It's not allways faster ... it really depends on how many matc

Re: Date ranges - getting the approach right

: I gather I should prefer RangeQuery to ConstantScoreQuery+RangeFilter, : because it is faster not to use a Filter. However, I sometimes have to It's not allways faster ... it really depends on how many matching terms there are in your range. : In a year of 365 days with e-mail messages arrivin

Date ranges - getting the approach right

For the sake of date ranges, I'm storing dates as MMDD in my e-mail indexing application. My users typically want to limit their queries to ranges of dates, which include today. The application is indexing in real time. I gather I should prefer RangeQuery to ConstantScoreQuery+RangeFilter, b