[ https://issues.apache.org/jira/browse/LUCENE-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973908#action_12973908 ]
Robert Muir commented on LUCENE-2829: ------------------------------------- bq. But, then, passing a struct (parent/sub/ord) is a fairly small change, and, if it "matches" the change we will make on LUCENE-2694, then that's great. Ok, that might be a good approach, to fix the it this way in LUCENE-2694 (or actually, preferably add the parent/sub/ord in its own issue!), but in 3.1 we could use the struct to avoid wasted seeks on PK terms... Seems like backporting the entire termstate thing could be a little tricky/risky for 3.1, with not much to gain there except PK lookups anyway, since the multitermqueries there tend to be slow (dominated by term comparison) and don't even work per-segment anyway. > 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