Thanks for all the replies! Mike: we're not using pf. Our qf is always "status:0". The "status" field is "0" for all good docs (90%+) and some other integer for any docs we don't want returned.
Jeyrl: federated search is definitely something we'll consider. On Fri, Sep 12, 2008 at 8:39 AM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: > The bottleneck may simply be there are a lot of docs to score since you are > using fairly common terms. Yeah, I'm coming to the realization that it may be as simple as that. Even a short, simple query like "shirt" can take seconds to return, presumably because it hits ("numFound") 2 million docs. > Also, what file format (compound, non-compound) are you using? Is it > optimized? Have you profiled your app for these queries? When you say the > "query is longer", define "longer"... 5 terms? 50 terms? Do you have lots > of deleted docs? Can you share your DisMax params? Are you doing wildcard > queries? Can you share the syntax of one of the offending queries? I think we're using the non-compound format. We see eight different files (fdt, fdx, fnm, etc.) in an optimized index. Yes, it's optimized. It's also read-only---we don't update/delete. DisMax: we specify qf, fl, mm, fq; mm=1; we use boosts for qf. No wildcards. Example query: "shirt"; takes 2 secs to run according to the solr log, hits 2 million docs. > Since you want to keep "stopwords", you might consider a slightly better > use of them, whereby you use them in n-grams only during query parsing. Not sure what you mean here... > See also https://issues.apache.org/jira/browse/LUCENE-494 for related > stuff. > Thanks for the pointer. Jason