: for reasons forthcoming. The QParser then just returns a
: ConstantScoreQuery wrapped around a Filter subclass that I wrote which uses
: these Terms. The Filter subclass does most of the "work".
If there is a lot of overlap in the Terms that are used from query to
query, you might find it more efficient to construct individual
TermFilters for each term, and utilize the filterCache to reuse them from
request to request -- then your plugin (it would probably have to be
a SearchComponent instead of a QParser) would only need to find the union
of the individual DocSets
: Correct me if I'm wrong, but it seemed important to have my input terms in
: natural order of a TreeSet in order to take advantage of the seek() approach
: to TermDocs (presuming it is sort of like a database cursor?).
(I believe) You are correct .. seek can only move ahead.
: In any event, we're getting rougly 2-3 second query times, with an
: additional 1-2 seconds parsing input from the request. so our local client
: app sees about a 6-8 second roundtrip on it's queries, with faceting turned
: on. For such a large query: not bad!
Unless the individual terms tend to be extermely unique, or your are
opening a new search extremeley frequently, i would suggest you try the
filterCache and DocSet union based approach....
DocSet main = BitDocSet();
for (Term t : myTerms) {
main = searcher.getDocSet(new TermQuery(t)).union(main);
}
-Hoss
