I would expect a filter to be quicker than adding thousands of clauses because Filters are just bit sets and operations are extremely fast. But never take performance predictions, particularly from me, on trust - test it in your app with your index on your hardware.
To use a filter here I think you'd create a Filter subclass with a getDocIdSet() method that returned a DocIdSet, probably an OpenBitSet, that had the relevant bits set. Presumably you're aware of the transient nature of lucene internal docids and the per-segment complexities and everything. -- Ian. On Wed, Oct 17, 2012 at 3:50 PM, sxam <sx...@yahoo.com> wrote: > Hi, > Well, those are Lucene Document Ids I am talking about. And I know it could > be done using a Filter with a Query, but I thought that if I can tell Lucene > to somehow look in a specified set of Documents, it would speed up the > search substantially. Otherwise it's just the same as adding 5000 Clauses to > the search query isn't it? > Or am I missing something and using Filter is better than in a search query? > But why, isn't Filter using the same query ifc and just works on a received > result set? How do I add Document Id as a clause (to Filter/Query), BTW? > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Restrict-Lucene-search-in-concrete-document-ids-tp4013905p4014258.html > Sent from the Lucene - Java Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org