: We currently are intersecting a precalculated OpenBitSet (that does not
: affect score) with search by adding it to the filters in the ResponseBuilder
: via a wrapped in a ConstantScoreQuery and Filter. We do this just before
: QueryComponent does its job.
...
: But, it does more work than needed. Wouldn't it be better to just intersect
: this set with the results after they are determined? To do this, Query
: Component needs a place to allow intersections before it stuffs the response
: in the response.
I think a simpler approach might be to write a component that runs after
QueryComponent which:
* extracts the doclist/set currently in the response (by QueryComponent)
* intersects them with the computed bitsets
* writes the new doclist/docset back into the response
However: i wouldn't actaully assume that's better then your current
approach of wrapping the OpenBitSet into a ConstantScoreQuery -- your
current approach is probably helping the the IndexSearcher "skip" past a
lot of docs w/o scoring them, but applying the intersection after the fact
would eliminate that optimization.
It's also very hard to compute a DocList from an intersection after the
fact ... you essentially need to re-execute the search anyway since it
only keeps track of a set number of sorted documents.
-Hoss
