[
https://issues.apache.org/jira/browse/LUCENE-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cédrik LIME updated LUCENE-2015:
Attachment: ASCIIFoldingFilter-no_formatting.patch
As suggested by Robert, here is a new version
OK, again!
I've built new release artifacts from svn rev 832363 (on the 2.9
branch), here:
http://people.apache.org/~mikemccand/staging-area/rc4_lucene2.9.1/
Changes are here:
http://people.apache.org/~mikemccand/staging-area/rc4_lucene2.9.1changes/
Please vote to officially release these
[
https://issues.apache.org/jira/browse/LUCENE-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773000#action_12773000
]
Earwin Burrfoot commented on LUCENE-1997:
-
bq. though they'd have preferred no
[
https://issues.apache.org/jira/browse/LUCENE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773001#action_12773001
]
Michael McCandless commented on LUCENE-504:
---
Since 3.0 is now on Java 1.5, can't
[
https://issues.apache.org/jira/browse/LUCENE-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773012#action_12773012
]
Michael McCandless commented on LUCENE-1997:
bq. Another observation, with
[
https://issues.apache.org/jira/browse/LUCENE-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773014#action_12773014
]
Robert Muir commented on LUCENE-2015:
-
Cédrik, thanks!
at a glance this looks good to
+1
On Nov 3, 2009, at 2:05 AM, Michael McCandless wrote:
OK, again!
I've built new release artifacts from svn rev 832363 (on the 2.9
branch), here:
http://people.apache.org/~mikemccand/staging-area/rc4_lucene2.9.1/
Changes are here:
[
https://issues.apache.org/jira/browse/LUCENE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773329#action_12773329
]
John Wang commented on LUCENE-2026:
---
+1
Refactoring of IndexWriter
[
https://issues.apache.org/jira/browse/LUCENE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773098#action_12773098
]
Uwe Schindler edited comment on LUCENE-504 at 11/3/09 6:27 PM:
Mark, I'm not stuck on single examples, I'm thinking about all of lucene
land: what tiny fraction of people need the combined intersection of
a) many many segments
AND
b) deep paging
AND
c) high QPS
AND
e) can't handle another 40MB of RAM usage.
Only people in the intersection of
[
https://issues.apache.org/jira/browse/LUCENE-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773114#action_12773114
]
Jake Mannix commented on LUCENE-1997:
-
bq. Since each approach has distinct
[
https://issues.apache.org/jira/browse/LUCENE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773098#action_12773098
]
Uwe Schindler commented on LUCENE-504:
--
We had a discussion about that in another
Not *ever* being able to optimize is a common case, without jumping a
lot of hoops. There are many systems that need to be on nearly 24/7 -
an optimize on a large index can take many hours - usually an unknown
number. Linkedin and it's use cases are not the only consumers of
lucene.
-
Ability to turn off the store for an index
--
Key: LUCENE-2025
URL: https://issues.apache.org/jira/browse/LUCENE-2025
Project: Lucene - Java
Issue Type: New Feature
Components: Index
[
https://issues.apache.org/jira/browse/LUCENE-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773298#action_12773298
]
Mark Miller commented on LUCENE-1997:
-
If this is about ease of use, its pretty easy
I use a low merge factor now too - and recomend it to others. But a
lot of users like to use crazy high merge factors.
I'm not arguing the absolute worst case is common. It almost never is.
- Mark
http://www.lucidimagination.com (mobile)
On Nov 3, 2009, at 12:52 PM, Jake Mannix
The memory issue is just one example of something that's somewhat
worse - I don't see it as a deciding faster. If things were clarified
to be decidedly faster with multi queue, and not 50% worse at 1000
hits, I'd be for the change, more memory or not.
- Mark
Um, according to Mike's latest numbers, multiPQ is actually *faster* at 1000
hits sometimes. In fact, all of the most recent tests have shown no clear
winner either way in terms of QPS. Sometimes (look at Yonik's linux
numbers), multiPQ is nearly across the board faster.
Either way, I think
Refactoring of IndexWriter
--
Key: LUCENE-2026
URL: https://issues.apache.org/jira/browse/LUCENE-2026
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael Busch
There are really not that many hoops you need to jump through to be able to
periodically optimize down to 10 segments or so. I've used lucene at plenty
of other places before LinkedIn, and rarely (since 2.3's indexing speed blew
through the roof) have I had to worry about setting the merge factor
Your obviously too stuck on single examples. We have to consider
everyone in lucene land.
I'm against 2 Apis. A custom search is advanced - it's not worth the
baggage of maintaining two APIs or be limited by the APIs and back
compat when moving forward.
If the advantage of the second API
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/998/
--
[...truncated 1575 lines...]
AU
contrib/benchmark/src/java/org/apache/lucene/benchmark/quality/utils/package.html
AU
[
https://issues.apache.org/jira/browse/LUCENE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773402#action_12773402
]
Nadav Har'El commented on LUCENE-504:
-
Hi Uwe, I think that even though PriorityQueue
23 matches
Mail list logo
