See http://hudson.zones.apache.org/hudson/job/Solr-3.x/33/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[
https://issues.apache.org/jira/browse/LUCENE-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876577#action_12876577
]
Andrzej Bialecki commented on LUCENE-2492:
---
How about adding some metadata to
Are you sure you have uniqueKey field in your lucene index?
Distributed search needs it.
Koji Sekiguchi from mobile
On 2010/06/08, at 15:52, Scott Zhang macromars...@gmail.com wrote:
Hi. All.
I am coming from solr user mailing list. I got a problem with
distributed search. Looks it
Hi. Koji.
Not sure how to set uniqueKey field in my lucene index. I am creating it
by using lucene.net
Document doc = new Document();
doc.Add(new Field(id, product_obj.product_id.ToString(),
Field.Store.YES, Field.Index.UN_TOKENIZED));
doc.Add(new Field(type, product,
I checked my existing lucene indexes. All the ID field are stored but
not indexed. I don't want to rebuild these indexes as it will take days.
Can solr be changed a little let ID be not indexed?
Thanks.
On Tue, Jun 8, 2010 at 3:30 PM, Scott Zhang macromars...@gmail.com wrote:
Hi. Koji.
Not
[
https://issues.apache.org/jira/browse/SOLR-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated SOLR-1943:
Attachment: SOLR-1943.patch
This patch effectively adds a readme file and renames build.xml. Will
[
https://issues.apache.org/jira/browse/SOLR-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved SOLR-1943.
-
Resolution: Fixed
Committed revision: 952613
Disable clustering contrib in Solr trunk
[
https://issues.apache.org/jira/browse/LUCENE-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated LUCENE-2495:
--
Attachment: lucene-iostream.tar
Added classes:
LuceneDirectoryInputStream and
Add In/Out/putStream wrapper around Lucene IndexIn/Out/put
--
Key: LUCENE-2495
URL: https://issues.apache.org/jira/browse/LUCENE-2495
Project: Lucene - Java
Issue Type: New Feature
Hi Shai:
I am not sure I understand how changing Similarity would solve this
problem, wouldn't you need the reader?
As for PayloadTermQuery, payload is not always the most efficient way of
storing such data, especially when number of terms numdocs. (I am not
sure accessing the payload
thanks! found it already
On Tue, Jun 8, 2010 at 6:33 PM, Michael McCandless
luc...@mikemccandless.com wrote:
It's gene...@lucene.apache.org -- that list has been around forever.
We are generally (heh) supposed to do the release vote on general,
but in the past we have also done it on dev.
If
re: But Scorer is itself an iterator, so what prevents you from calling
nextDoc and advance on it without score()
Nothing. It is just inefficient to pay the method call overhead just to
overload score.
re: If I were in your shoes, I'd simply provider a Query wrapper. If CSQ
is not good enough
I guess I must be missing something fundamental here :).
If Scorer is defined as you propose, and I create my Scorer which impls
getDISI() as return this - what do I lose? What's wrong w/ Scorer already
being a DISI?
You mention it is just inefficient to pay the method call overhead ... -
what
The problem with your proposal is that, currently, Lucene uses current
iteration state to compute score.
I.e. it already knows which of SHOULD BQ clauses matched for current
doc, so it's easier to calculate the score.
If you change API to allow scoring arbitrary documents (even those
that didn't
Shai, his wrapper Scorer will just look like:
DISI getDISI() {
return delegate.getDISI();
}
float score(int doc) {
return calcMyAwesomeScore(doc);
}
this saves delegate.nextDoc(), delegate.advance() indirection calls.
But I already offered a better alternative :)
On Tue, Jun 8, 2010 at
Shai:
method call overhead in this case is not insignificant because it is in
a very tight loop, and no, compiler cannot optimize it for you, we are not
inline-ing cuz we are in a java world.
You are right, this breaks backward compatibility. But from 2.4 - 2.9,
we have done MUCH worse.
Shai:
Java cannot inline in this case.
Actually there is an urban legend around using final to hint to
underlying compiler to inline :) (turns out to be false, one reason being
dynamic classloading)
write a simple pgm and try and see for yourself (remember to turn on
-server on VM
Wouldn't you get it as well with proposed api?
You would still be able to iterate the doc and at that point call score with
the docid. If you call score() along with iteration, you would still get the
information no?
Making scorer take a docid allows you score any docid in the reader if the
query
Some people don't do IO while searching at all. When you're over
certain qps/index size threshold, you need less nodes to keep all your
index (or its hot parts) in memory, than to keep combined IO subsystem
throughput high enough to satisfy disc-based search demands.
2010/6/9 Doron Cohen
See http://hudson.zones.apache.org/hudson/job/Lucene-3.x/36/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
20 matches
Mail list logo
