InstantiatedIndexReader.clone
-
Key: LUCENE-1537
URL: https://issues.apache.org/jira/browse/LUCENE-1537
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/*
Affects Versions: 2.4
I've taken a quick peek at TrieUtils/TrieRangeQuery - nice work Uwe!
One general comment is that it seems like TrieUtils tries to do a
little too much for users (and in the process covers up some
functionallity).
For example, whether to encode values in two fields and exactly what
those fields are
[
https://issues.apache.org/jira/browse/LUCENE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Rutherglen updated LUCENE-1314:
-
Attachment: LUCENE-1314.patch
Now that we've got IndexReader.getSequentialSubReaders(),
[
https://issues.apache.org/jira/browse/LUCENE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671362#action_12671362
]
jasonrutherglen edited comment on LUCENE-1314 at 2/6/09 2:43 PM:
---
Hi Yonik,
> I've taken a quick peek at TrieUtils/TrieRangeQuery - nice work Uwe!
Thank you :-)
Some words before: I made the original "TrieRangeQuery" about middle of
2005, when Lucene 1.4.3 was on the market, closed source for PANGAEA
(www.pangaea.de). At this time there was no ConstantScoreQue
I just ran into the same bottleneck with ValueSourceScorer.
Here's a stack trace:
Name: QueryThread group 1,#4
State: BLOCKED on org.apache.lucene.index.segmentrea...@49d7fb83 owned by:
QueryThread group 1,#8
Total blocked: 1,535,881 Total waited: 1,080
Stack trace:
org.apache.lucene.index.Segme
Indeed!
I'll open an issue...
Thanks Peter.
Mike
Peter Keegan wrote:
I just ran into the same bottleneck with ValueSourceScorer.
Here's a stack trace:
Name: QueryThread group 1,#4
State: BLOCKED on org.apache.lucene.index.segmentrea...@49d7fb83
owned by: QueryThread group 1,#8
Total blo
ValueSourceQuery hits synchronization bottleneck in IndexReader.isDeleted
-
Key: LUCENE-1538
URL: https://issues.apache.org/jira/browse/LUCENE-1538
Project: Lucene - Java
OK I created https://issues.apache.org/jira/browse/LUCENE-1538.
Mike
Peter Keegan wrote:
I just ran into the same bottleneck with ValueSourceScorer.
Here's a stack trace:
Name: QueryThread group 1,#4
State: BLOCKED on org.apache.lucene.index.segmentrea...@49d7fb83
owned by: QueryThread gro
[
https://issues.apache.org/jira/browse/LUCENE-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1538:
---
Attachment: LUCENE-1538.patch
Patch attached. I plan to commit in a day or two.
>
Thanks, Mike. I'll be happy to help test the patch.
Peter
On Fri, Feb 6, 2009 at 6:44 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
>
> OK I created https://issues.apache.org/jira/browse/LUCENE-1538.
>
> Mike
>
>
> Peter Keegan wrote:
>
> I just ran into the same bottleneck with Va
OK I just put the patch on there -- let me know. Thanks,
Mike
Peter Keegan wrote:
Thanks, Mike. I'll be happy to help test the patch.
Peter
On Fri, Feb 6, 2009 at 6:44 PM, Michael McCandless > wrote:
OK I created https://issues.apache.org/jira/browse/LUCENE-1538.
Mike
Peter Keegan wro
On Fri, Feb 6, 2009 at 6:18 PM, Uwe Schindler wrote:
>> Encoding a slice per character makes the code simpler, but increases
>> the size of the index... but perhaps not enough to worry about in
>> practice?
>
> This is correct. For 2bit and 4bit there is a lot of overhead by this, but
> there is n
On Fri, Feb 6, 2009 at 6:18 PM, Uwe Schindler wrote
> The encoding of the values
> into two different field names does the trick for the whole range query.
> Removing the code that generates the field in exactly that way would remove
> the idea behind TrieRangeFilter.
Allowing the ability to spec
Greets,
Lucy needs sophisticated search-time benchmarking. The obvious approach is to
port the Lucene contrib benchmark suite.
However, contrib benchmark has a large number of classes, the documentation is
sparse and occasionally wrong ("Usage: java Benchmark algorithm-file"),
there's no howto
After an NPE and a quick gander at SegmentReader, it looks like it's
trying to clone the norms for *all* fields, regardless of if they are
indexed.
The following is the simplest patch that seems to fix things, but I'm
wondering if other changes might be warranted (like where
fieldNormsChanged is se
It looks like this was introduced just recently in LUCENE-1314.
I've just committed this fix along with test modifications that fail
w/o this patch.
-Yonik
On Fri, Feb 6, 2009 at 10:15 PM, Yonik Seeley
wrote:
> After an NPE and a quick gander at SegmentReader, it looks like it's
> trying to clon
17 matches
Mail list logo
