Re: ScorerDocQueue.HeapedScorerDoc

Op Saturday 26 July 2008 23:09:06 schreef eks dev: > what is the reason to have HeapedScorerDoc class in ScorerDocQueue? > Caching of the doc value? Yes. The underlying priority queue does log2(n) comparisons on them on some occasions. > Does this bring anything compared to > invoking doc() on S

Re: [jira] Commented: (LUCENE-1345) Allow Filter as clause to BooleanQuery

Hi Paul, it sounds so familiar. I too like playing with lucene, makes fun, but I have not found formula to make 25 Hours day (waking up one hour earlier does not work for me for some strange reason) The only other person being so interested in this Filter-like issues is Yonik, but I guess he ha

[jira] Commented: (LUCENE-1345) Allow Filter as clause to BooleanQuery

[ https://issues.apache.org/jira/browse/LUCENE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617220#action_12617220 ] Paul Elschot commented on LUCENE-1345: -- Thanks for the DisjunctionDISI.patch. I had j

ScorerDocQueue.HeapedScorerDoc

what is the reason to have HeapedScorerDoc class in ScorerDocQueue? Caching of the doc value? Does this bring anything compared to invoking doc() on Scorer, just curious, maybe I do not see something ovious... If doc is the reason, I would bet on doc() ___

[jira] Updated: (LUCENE-1345) Allow Filter as clause to BooleanQuery

[ https://issues.apache.org/jira/browse/LUCENE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eks Dev updated LUCENE-1345: Attachment: DisjunctionDISI.patch bq. Would anyone have a DisjunctionDISI (Disjunction over DocIdSetIterat

[jira] Commented: (LUCENE-1336) Distributed Lucene using Hadoop RPC based RMI with dynamic classloading

[ https://issues.apache.org/jira/browse/LUCENE-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617188#action_12617188 ] Jason Rutherglen commented on LUCENE-1336: -- The classloading mechanism described

[jira] Resolved: (LUCENE-1203) [PATCH] Allow setting IndexReader to IndexSearcher

[ https://issues.apache.org/jira/browse/LUCENE-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved LUCENE-1203. -- Resolution: Won't Fix Lucene Fields: [New, Patch Available] (was: [Patch Available, New

[jira] Commented: (LUCENE-1340) Make it posible not to include TF information in index

[ https://issues.apache.org/jira/browse/LUCENE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617143#action_12617143 ] Michael McCandless commented on LUCENE-1340: OK that sounds like a healthy tes

Re: LUCENE-1315 status?

I'm less familiar with IndexSearcher, but I agree this issue (LUCENE-1203 is the original one) has been open for quite a while and there seems to be some demand to set an IndexReader on an existing IndexSearcher. However, I think Yonik spells out the concerns in LUCENE-1203: each insta

[jira] Resolved: (LUCENE-1315) Add setIndexReader in IndexSearcher

[ https://issues.apache.org/jira/browse/LUCENE-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1315. Resolution: Duplicate Lucene Fields: [New, Patch Available] (was: [Patch Av

[jira] Commented: (LUCENE-1340) Make it posible not to include TF information in index

[ https://issues.apache.org/jira/browse/LUCENE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617140#action_12617140 ] Eks Dev commented on LUCENE-1340: - we finished our tests Index without omitTf() : - 87Mi