+1 I think it ought to be faster? PrefixTermEnum just calls .startsWith on each term text, but WildcardTermEnum has big hairy logic in wildcardEquals.
Mike On Tue, Oct 6, 2009 at 11:43 PM, Robert Muir <rcm...@gmail.com> wrote: > separately, perhaps we should consider doing the prefixquery rewrite > here for wildcardquery. > > for example, SolrQueryParser will emit these 'wildcardqueries that > should be prefixqueries' if you are using the new reverse stuff for > leading wildcards: WildcardQuery(*foobar) -> > WildcardQuery(U+0001raboof*) > > I don't think the prefix enumeration is really that much faster than > the wildcard one, but still thought I would mention it. > > On Tue, Oct 6, 2009 at 10:22 PM, Robert Muir <rcm...@gmail.com> wrote: >> someone asked this question on the user list: >> http://www.lucidimagination.com/search/document/6f38de391b242102/prefixquery_vs_wildcardquery >> >> it made me look at the wildcard rewrite(), where i see this: >> if (!termContainsWildcard) >> return new TermQuery(getTerm()); >> >> is it a problem the boost is not preserved in this special case? >> >> is it also a problem that if the user sets the default MultiTermQuery >> rewriteMethod to say, CONSTANT_SCORE_FILTER_REWRITE, >> that this rewritten TermQuery isn't wrapped with a constant score? >> >> Sorry if it seems a bit nitpicky, really the issue is that I want to >> do the right thing for a more complex query I am working on, but don't >> want to overkill either. >> -- >> Robert Muir >> rcm...@gmail.com >> > > > > -- > Robert Muir > rcm...@gmail.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
