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 < [email protected]> wrote: > On Tue, May 19, 2009 at 8:50 AM, Robert Muir <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Robert Muir [email protected]
