[
https://issues.apache.org/jira/browse/LUCENE-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974262#action_12974262
]
Michael McCandless commented on LUCENE-2829:
--------------------------------------------
bq. The cache has a number of advantages that may never be duplicated in a
different type of API
+1 -- I agree we should keep the TermState cache. It has benefits outside of
re-use win a single query.
But allowing term-lookup-intensive clients like MTQ to do their own caching
(ie pulling the TermState from the enum) is also important. I think we need
both.
On caching misses... that makes me nervous. If there are apps out there that
do alot of checking for terms that don't exist that can destroy the cache.
The cache is a great safety net but I think our core queries should be good
consumers, when possible, and hold their own TermState.
> improve termquery "pk lookup" performance
> -----------------------------------------
>
> Key: LUCENE-2829
> URL: https://issues.apache.org/jira/browse/LUCENE-2829
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Robert Muir
> Attachments: LUCENE-2829.patch
>
>
> For things that are like primary keys and don't exist in some segments (worst
> case is primary/unique key that only exists in 1)
> we do wasted seeks.
> While LUCENE-2694 tries to solve some of this issue with TermState, I'm
> concerned we could every backport that to 3.1 for example.
> This is a simpler solution here just to solve this one problem in
> termquery... we could just revert it in trunk when we resolve LUCENE-2694,
> but I don't think we should leave things as they are in 3.x
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
