lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-2829) improve termquery "pk lookup" performance
Date Wed, 22 Dec 2010 16:27:00 GMT


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:
>             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:
For additional commands, e-mail:

View raw message