[jira] Commented: (LUCENE-1693) AttributeSource/TokenStream API improvements

[ https://issues.apache.org/jira/browse/LUCENE-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732869#action_12732869 ] Michael McCandless commented on LUCENE-1693: bq. Given the difficulty of using

RE: constant-score rewrite mode for NumericRangeQuery

Hi Mike, I did some perf tests with the well-known PerfTest.java from the FieldCacheRangeFilter JIRA issue. I compared a 5 mio doc index with precStep=4: With constant score rewrite: avg number of terms: 68.3 TRIE: best time=6.192687 ms; worst time=463.0907 ms; avg=222.6431290998 ms; sum=31

[jira] Commented: (LUCENE-1693) AttributeSource/TokenStream API improvements

[ https://issues.apache.org/jira/browse/LUCENE-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732878#action_12732878 ] Uwe Schindler commented on LUCENE-1693: --- In this case we should rename TeeSink to so

[jira] Issue Comment Edited: (LUCENE-1693) AttributeSource/TokenStream API improvements

[ https://issues.apache.org/jira/browse/LUCENE-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732878#action_12732878 ] Uwe Schindler edited comment on LUCENE-1693 at 7/18/09 4:06 AM:

Throttling merges

It may be useful to allow users to throttle merges. A callback that IW passes into SegmentMerger would suffice where individual SM methods make use of the callback. I suppose this could slow down overall merging by adding a potentially useless method call. However if merging typically consumes IO r

Re: constant-score rewrite mode for NumericRangeQuery

On Sat, Jul 18, 2009 at 6:54 AM, Uwe Schindler wrote: > I did some perf tests with the well-known PerfTest.java from the > FieldCacheRangeFilter JIRA issue. > > I compared a 5 mio doc index with precStep=4: > > With constant score rewrite: > avg number of terms: 68.3 > TRIE: best time=6.192687 ms;

[jira] Updated: (LUCENE-1750) Create a MergePolicy that limits the maximum size of it's segments

[ https://issues.apache.org/jira/browse/LUCENE-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated LUCENE-1750: - Issue Type: Improvement (was: Bug) Summary: Create a MergePolicy that limits the

[jira] Updated: (LUCENE-1750) Create a MergePolicy that limits the maximum size of it's segments

[ https://issues.apache.org/jira/browse/LUCENE-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated LUCENE-1750: - Fix Version/s: (was: 2.9) 3.1 > Create a MergePolicy that limits

[jira] Updated: (LUCENE-1742) Wrap SegmentInfos in public class

[ https://issues.apache.org/jira/browse/LUCENE-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1742: --- Attachment: LUCENE-1742.patch Attached patch with tiny changes: made a few more read

Re: Throttling merges

The goal is to be like "ionice" right? Meaning, lower the priority of IO caused by merging? I agree that makes sense. I wonder if we could implement it in the Directory level, so that when openInput/createOutput is called we can optionally specify the "context" (reader, merging, writer, etc.), a

[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract

[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732938#action_12732938 ] Earwin Burrfoot commented on LUCENE-1748: - bq. We should drop PayloadSpans and jus

[jira] Commented: (LUCENE-1750) Create a MergePolicy that limits the maximum size of it's segments

[ https://issues.apache.org/jira/browse/LUCENE-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732974#action_12732974 ] Shai Erera commented on LUCENE-1750: What happens after several such large segments ar