Lucene 5.0 introduced two-phase iteration (see Scorer.twoPhaseIterator()) as a way to tackle slow queries. In short, queries can be split into a fast approximation and a slower confirmation and Lucene makes sure to reach agreement between the different approximations of a BooleanQuery before checking the confirmations.
Both approximations and confirmations have an API that allows them to expose a "cost" and the least costly components are always evaluated before the most costly ones. So the filter strategy is not useful anymore, every decision is made based on these cost APIs. Le ven. 22 juil. 2016 à 15:32, Andres de la Peña <adelap...@stratio.com> a écrit : > Hi all, > > Suppose that we have a boolean query composed by two filtering queries, > where one of them is fast and the other is slow: > > BooleanQuery.Builder builder = new BooleanQuery.Builder(); > builder.add(fastQuery, FILTER); > builder.add(slowQuery, FILTER); > Query query = builder.build(); > > > How is the intersection between the two sub-queries calculated? Is the > order in which they are added to the boolean query relevant? Is there > something we could do to take advantage of my knowledge about the expected > performance of the sub-queries? > > Prior to Lucene 6.0 there was a FilteredQuery.FilterStrategy providing some > control about this. Is there something analogous in Lucene 6.0? > > Thanks in advance, > > -- > Andrés de la Peña > > Vía de las dos Castillas, 33, Ática 4, 3ª Planta > 28224 Pozuelo de Alarcón, Madrid > Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd > <https://twitter.com/StratioBD>* >
