britske wrote: > > 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. > that sounds great, is there really a way to do that?
britske wrote: > >>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 >> >> > > that's also something that i'll integrate into my testing environment, thanks -- View this message in context: http://lucene.472066.n3.nabble.com/filter-query-on-timestamp-slowing-query-tp977280p994679.html Sent from the Solr - User mailing list archive at Nabble.com.
