[
https://issues.apache.org/jira/browse/LUCENE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102393#comment-13102393
]
Robert Muir commented on LUCENE-3426:
-------------------------------------
I think I like it better too... though I wonder if its possible to keep the
original NGramPhraseQuery unmodified?
this way its not changed by Query.rewrite(), and if a user reuses the query
(which we document they can do), they could then call add() again and
everything works.
Also, somewhat related to the issue might be SOLR-2660. We don't have to commit
that patch, but we could separate
out the queryparser refactoring to make it easier for such an optimization to
be "automatic" in solr, because it allows
SolrQueryParser to delegate creation of Phrase/MultiPhraseQuery to the
FieldType.
> optimizer for n-gram PhraseQuery
> --------------------------------
>
> Key: LUCENE-3426
> URL: https://issues.apache.org/jira/browse/LUCENE-3426
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
> Reporter: Koji Sekiguchi
> Priority: Trivial
> Attachments: LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch,
> PerfTest.java
>
>
> If 2-gram is used and the length of query string is 4, for example q="ABCD",
> QueryParser generates (when autoGeneratePhraseQueries is true)
> PhraseQuery("AB BC CD") with slop 0. But it can be optimized PhraseQuery("AB
> CD") with appropriate positions.
> The idea came from the Japanese paper "N.M-gram: Implementation of Inverted
> Index Using N-gram with Hash Values" by Mikio Hirabayashi, et al. (The main
> theme of the paper is different from the idea that I'm using here, though)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
