[
https://issues.apache.org/jira/browse/LUCENE-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974350#action_12974350
]
Earwin Burrfoot commented on LUCENE-2829:
-----------------------------------------
Nobody halts your progress, we're merely discussing.
I, on the other hand, have a feeling that Lucene is overflowing with "single
incremental improvements" aka "hacks", as they are easier and faster to
implement than trying to get a bigger picture, and, yes, rebuilding everything
:)
For example, better term dict code will make this issue (somewhat hackish,
admit it?) irrelevant. Whether we implement bloom filters, or just guarantee to
keep the whole term dict in memory with reasonable lookup routine (eg. as FST).
Having said that, I reiterate, I'm not here to stop you or turn this issue into
something else.
> 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
