Hi Mikhail, Thanks for your answer!
> Here are two answers. Order of calling BQ.Builder.add() doesn't decide the > order of execution, as well as occur. > BooleanQuery lazily executes intersection dynamically and adjusts to actual > values, with many conditions and spec cases. Understood! > However, if you check SolrIndexSearcher.getProcessedFilter() you notice > that it executes filters eagerly and cache them (both up to parameters). > So, here the filterQuery in most cases will be bitset (or other) ie > materialized filter. Understood, I checked the getProcessedFilter() method in the source code, and it was as you explained. > It depends on relative selectivity (number of matched documents) of q and fq. > In an edge case deferring filters with cost>100 might get significant gain. I didn’t quite understand this part. Could you explain it in more detail please? Are you saying that the overall search performance differs depending on the number of documents matched by q and fq, due to the varying load of calculating the intersection? Or are you suggesting that the load of the filtering process in the filterQuery can change depending on the number of documents matched by q and fq as well? My understanding was that the filterQuery is executed independently of the scoreQuery, applying the filter logic to the entire index and then calculating the intersection of the respective results. Therefore, I thought the processing order of q and fq wouldn’t affect the overall search performance. Regards, Mingchun
