I presume your search steps are anded, as in typical drill-downs? >From a Lucene standpoint, each sequence of steps is a BooleanQuery of required clauses, one for each step. To add a step, you extend the BooleanQuery with a new clause. To not re-evaluate the full query, you'd need some query that regenerated the results of the prior step more efficiently than BooleanQuery. For example, if you happened to generate the entire result set for each step, presumably not feasible, then the results might be cached for regeneration. Assuming you cannot generate the entire result set, it's not obvious to me how having partially generated S1 and ... Sn-1 will help you generate S1 and ... Sn any faster.
You will already get the the benefit of OS caching with Lucene as it stands. You might find further caching extension to the query types you use to be a performance gain that achieves what you want. You might also consider some kind of query optimization by extending the rewrite() methods. Chuck Fernando Mato Mira wrote on 08/28/2006 12:21 AM: > Hello, > > We think we would have a problem if we try to use lucene because we > do search combinations which might have hundreds of steps, so creating > a combined query and executing again each time might be a problem. > What would entail overhauling Lucene to do search combinations by > taking advantage of the results already generated? > > Thanks > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
