: quick. I'm using Lucene version 2.4.1
...
: and QueryParser. The search results between the two queries are now in
: different orders while the number of results are the same. I have one
: Old Way
: QueryParser parser = new QueryParser("words", analyzer);
: Query q = parser.parse("+wo
Hi Michael,
On 25/03/10 19:15, Michael McCandless wrote:
I am using one single thread for indexing: reading sequentially the list of
wikipedia articles, putting the content into a single field, and add the
document to the index. Commit is done every 10K documents.
Are you using contrib/be
Yeah. I was thinking about of those. I don't want to upgrade as it is in
production. I can't get a test case that reproduces the issue for some reason.
I might need the production data set to test with.
I'll definitely try an explain and see what the heck is going on.
For now, I just reverted t
define fun ;-)
indeed I created a custom indexing chain, plugged it in and all works well.
I'm currently trying to isolate the critical parts to double test that
indeed most of the time goes in the indexing process.
It's kind of hard doing accurate measurements bc. the indexer is designed to
be r
oops, forgot the attachments... its here now...
On 3/26/2010 10:33 AM, Siraj Haider wrote:
Hi Mike,
I am attaching the dump that I created by putting
-XX:+PrintClassHistogram in catalina options and by issuing a kill -3
command. The machine was not in a bad state (i.e. it was not doing
frequen
Hi Mike,
I am attaching the dump that I created by putting
-XX:+PrintClassHistogram in catalina options and by issuing a kill -3
command. The machine was not in a bad state (i.e. it was not doing
frequent Full GC cycles yet) but the kill -3 forced it to do a Full GC.
If you want I will wait
What will your search look like?
If your document is:
f1:"1"
f2:"2"
f3:"3"
You could create a lucene document with a single field instead of 20k:
fields:"f1/1 f2/2 f3/3"
I replaced ":" with "/" and let assume you use whitespace analyzer on
indexing.
On search your old query "+f1:1 +f2:2" should
I live in Melbourne Australia, and am involved in several
high-transaction SOLR servers.
On 3/25/10 8:39 AM, Erick Erickson wrote:
No clue, but you might get more responses by asking on the SOLR
users' list.
You might be able to get something from the "Powered by SOLR" page
at: http://wiki
This sounds like fun :)
So you've already created a custom indexing chain, and plugged this
into DocumentsWriter? And this chain directly interacts with the low
level classes for writing a segment (FormatPostingsTerms/DocsConsumer,
etc.)?
I'm not sure you're gonna do much better than that... the
Odd. Query.toString() and back to Query via parser are not guaranteed
to be consistent but it looks pretty straightforward in this case.
Maybe Searcher.explain would give a clue. Or post a minimal
self-contained program or test case that demonstrates this. Or try a
later version of lucene.
--
On Fri, Mar 26, 2010 at 1:17 AM, Daniel Noll wrote:
> On Thu, Mar 25, 2010 at 21:41, Michael McCandless
> wrote:
>>
>> This depends on the particulars of filter... but in general you
>> shouldn't have to consume more RAM, I think? Ie you should be able to
>> do your computation against the top-l
11 matches
Mail list logo
