[ 
https://issues.apache.org/jira/browse/LUCENE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-2351:
---------------------------------------

    Attachment: LUCENE-2351.patch

Patch to adress some of the optos:

  * Adds optional "boolean useCache" to TermsEnum.seek

  * Adds protected FilteredTermsEnum.set/getUseTermsCache, so each query type 
can choose (defaults to false)

  * Switches to long[] gen in AutomatonTermsEnum.nextString

  * Use commonSuffixRef = null to mean there is no suffix

> optimize automatonquery
> -----------------------
>
>                 Key: LUCENE-2351
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2351
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: Flex Branch
>            Reporter: Robert Muir
>            Priority: Minor
>             Fix For: Flex Branch
>
>         Attachments: LUCENE-2351.patch
>
>
> Mike found a few cases in flex where we have some bad behavior with 
> automatonquery.
> The problem is similar to a database query planner, where sometimes simply 
> doing a full table scan is faster than using an index.
> We can optimize automatonquery a little bit, and get better performance for 
> fuzzy,wildcard,regex queries.
> Here is a list of ideas:
> * create commonSuffixRef for infinite automata, not just really-bad linear 
> scan cases
> * do a null check rather than populating an empty commonSuffixRef
> * localize the 'linear' case to not seek, but instead scan, when ping-ponging 
> against loops in the state machine
> * add a mechanism to enable/disable the terms dict cache, e.g. we can disable 
> it for infinite cases, and maybe fuzzy N>1 also.
> * change the use of BitSet to OpenBitSet or long[] gen for path-tracking
> * optimize the backtracking code where it says /* String is good to go as-is 
> */, this need not be a full run(), I think...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to