lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrien Grand <jpou...@gmail.com>
Subject Re: Filter strategy in Lucene 6.0
Date Sun, 31 Jul 2016 19:17:14 GMT
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 <adelapena@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>*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message