just wanted to mention a possible other route, which might be entirely hypothetical :-)
*If* you could query on internal docid (I'm not sure that it's available out-of-the-box, or if you can at all) your original problem, quoted below, could imo be simplified to asking for the last docid inserted (that match the other criteria from your use-case) and in the next call filter from that docid forward. >Every 30 minutes, i ask the index what are the documents that were added to >it, since the last time i queried it, that match a certain criteria. >From time to time, once a week or so, i ask the index for ALL the documents >that match that criteria. (i also do this for not only one query, but >several) >This is why i need the timestamp filter. Again, I'm not entirely sure that quering / filtering on internal docid's is possible (perhaps someone can comment) but if it is, it would perhaps be more performant. Big IF, I know. Geert-Jan 2010/7/23 Chris Hostetter <hossman_luc...@fucit.org> > : On top of using trie dates, you might consider separating the timestamp > : portion and the type portion of the fq into seperate fq parameters -- > : that will allow them to to be stored in the filter cache seperately. So > : for instance, if you include "type:x OR type:y" in queries a lot, but > : with different date ranges, then when you make a new query, the set for > : "type:x OR type:y" can be pulled from the filter cache and intersected > > definitely ... that's the one big thing that jumped out at me once you > showed us *how* you were constructing these queries. > > > > -Hoss > >
