是我的查询处理的理解是否正确？
- 从高速缓存或第一过滤查询获取文档集将创建实施OpenBitSet或SortedVIntSet和缓存它的
- 从缓存中获取文档集或所有其他过滤器创建的执行DocBitSet的，它会与原有的相交（ 此代码的效率取决于实现首先实现文档集的 ）
- 我们使用Lucene过滤器+搜索查询与MainQuery和最终文档集（全部交叉点后）跨越式（ 这个效率依赖于第一文档集实现 ）
- 我们采用后置滤波器（成本> 100 &&缓存==假）作为一部开拓创新的查询和
因此，作为结果的表现将取决于第一滤波器 ，因为对于小查询SortedIntSet是更有效和大的BitSet更好。 我对么？
问题的第二部分 ：文档集有两个主要的实现- HashDocSet和SortedIntDoc，每个路口实施迭代在第一过滤器的所有实例，并检查它是否也在第二文档集......这意味着我们必须按大小排序的过滤器，第一最小。 是否有可能控制缓存过滤器（成本仅为适用于非缓存过滤器）的顺序？
这听起来不错。 欲了解更多信息，看看SolrIndexSearcher＃getProcessedFilter 。
因此，作为结果的表现将取决于第一滤波器，因为对于小查询SortedIntSet是更有效和大的BitSet更好。 我对么？
这更多的是空间效率比速度的一个问题一个问题。 甲排序INT []成本4个* nDocs字节，而位组成本maxDoc / 8个字节，这是为什么Solr的用途来分类的INT []每当集合中的文件的数目是<maxDoc / 32。
问题的第二部分：文档集有两个主要的实现 - HashDocSet和SortedIntDoc
与SortedIntDocSet的问题是，它不支持随机访问，并与HashDocSet的问题是，它不能枚举文档ID的有序，这对于进球非常重要的。 这就是为什么Solr的使用SortedIntDocSets几乎无处不在，创建时，它需要随机访问一个短暂HashDocSet（看JoinQParserPlugin或DocSlice＃相交为例）。
