[
https://issues.apache.org/jira/browse/LUCENE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated LUCENE-3426:
-----------------------------------
Attachment: LUCENE-3426.patch
{quote}
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.
{quote}
I wonder it that too. Here is the new patch. This time I added
assertSame()/NotSame() to check the rewritten Query to test code.
> 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,
> 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
