none of my queries are "wicked fast" on 100M doc index! for narrow queries, we are talking about ~100ms queries becoming ~400ms or so with the constant score rewrite... for wide queries, we are talking about maybe 3 or 4s queries becoming 2s or so with the constant score rewrite..., it depends on how wide the query is...
I agree with fixing the "wicked slow" queries, but currently I think the general case would lose pretty bad (the way it works now), and only a corner case wins. On Tue, May 19, 2009 at 9:02 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Tue, May 19, 2009 at 8:50 AM, Robert Muir <rcm...@gmail.com> wrote: > > in my tests the problem seemed to boil down to iteration of a sparse > > openbitset... so maybe the filter approach is still an option but when # > > docs is small some other doc id set impl is used? > > Interesting... was your test a case where wicked fast queries became > only somewhat fast? Or did you actually see slowish queries get much > slower? > > In general, I'm less concerned about the former than the latter... I > think it's the wicked slow queries in Lucene that we need to focus on. > > Also, LUCENE-1536 (appply filters via random access API) should > independently address this, as well as filters-as-BooleanClause. > > But I'll include this in the issue; eg, I think MultiTermQuery could > choose sparse vs dense bit set impl > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Robert Muir rcm...@gmail.com
