Ouch, that's certainly a problem! I'll have to think some more on this
one.
Thanks for your time!
Matthew Runo
Software Engineer, Zappos.com
[EMAIL PROTECTED] - 702-943-7833
On Aug 19, 2008, at 1:42 PM, Otis Gospodnetic wrote:
Matthew, just because an index is read-only on some server it
d
Matthew, just because an index is read-only on some server it doesn't mean it
contains no deletes (no docs marked as deleted, but not yet removed from the
index). So you still want to check isDeleted(doc) *unless* you are certain the
index has no docs marked as deleted (this happens after optim
As long as Solr/Lucene makes smart use from memory (and they from my
experiences), it is really easy to calculate how long a huge query/update
will take when you know how much the smaller ones will take. Just keep in
mind that the resource consumption of memory and disk space is almost always
propo
I don't think it will help; for instance SegmentReader of Lucene:
public synchronized Document document(int n, FieldSelector fieldSelector)
Unsynchronized (in future) SOLR caching should help.
-Fuad
I know this isn't really the place for this, so please forgive me - but
does this patch loo
FYI, I just slipped this optimization into trunk.
-Yonik
On Tue, Aug 19, 2008 at 4:37 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> It doesn't matter that it's executed on the read-only server... it
> matters if any of the docs are marked as deleted. That's the
> condition that you probably wan
Solr has pluggable query parsers, but the default one is the Lucene one, so I'd
make use of Lucene's QueryParser.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Pierre Auslaender <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent
It doesn't matter that it's executed on the read-only server... it
matters if any of the docs are marked as deleted. That's the
condition that you probably want to check for.
-Yonik
On Tue, Aug 19, 2008 at 4:26 PM, Matthew Runo <[EMAIL PROTECTED]> wrote:
> I know this isn't really the place for
On 19-Aug-08, at 12:58 PM, Phillip Farber wrote:
So you experience differs from Mike's. Obviously it's an important
decision as to whether to buy more machines. Can you (or Mike)
weigh in on what factors led to your different take on local shards
vs. shards distributed across machines?
I know this isn't really the place for this, so please forgive me -
but does this patch look reasonably safe to use to skip the isDeleted
check inside of FunctionQuery?
My reasoning behind this is that many people (us included) will be
building the index on a separate server, and then using
I like this idea. Perhaps separate the solr version and the solr-ruby version
with a dash instead of dot -- solr-ruby-1.3.0-0.0.6
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> Fro
Thanks, Ian, for the considered reply. See below.
Ian Connor wrote:
I have not seen any boost by having an index split into shards on the
same machine. However, when you split it into smaller shards on
different machines (cpu/ram/hdd), the performance boost worth it.
So you experience differs
I have not seen any boost by having an index split into shards on the
same machine. However, when you split it into smaller shards on
different machines (cpu/ram/hdd), the performance boost worth it.
At least for building the index, the number of shards really does
help. To index Medline (1.6e7 do
A simple way is to query using debugQuery=true and parse the output:
0.74248177 = queryWeight(rawText:python), product of:
2.581456 = idf(docFreq=16017)
0.28762132 = queryNorm
0.4191762 = (MATCH) fieldWeight(rawText:python in 950285), product of:
5.196152 = tf(termFreq(rawText
On 19-Aug-08, at 10:18 AM, Phillip Farber wrote:
I'm trying to understand how splitting a monolithic index into
shards improves query response time. Please tell me if I'm on the
right track here. Were does the increase in performance come
from? Is it that in-memory arrays are smaller
I don't think so, as solr uses a flat index to represent data. I have some
efort towards representing relational data on a flat structure, but until
now I don't have anything too concrete.
My suggestion is: create classes that isolate the parsing strategy, so you
can have dao's that doesn't really
I'm trying to understand how splitting a monolithic index into shards
improves query response time. Please tell me if I'm on the right track
here. Were does the increase in performance come from? Is it that
in-memory arrays are smaller when the index is partitioned into shards?
Or is it
Hi Ian,
Thanks for the reply. I am using CURL, and the library was sending a GET
request to solr. But I have changed it to POST. Now it's working
properly.
Thanks,
Sunil
-Original Message-
From: Ian Connor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2008 7:53 PM
To: solr-user@lu
The query limit is a software imposed limit. What client are you using
and can that be configured to allow more?
On Tue, Aug 19, 2008 at 9:43 AM, Sunil <[EMAIL PROTECTED]> wrote:
> Hi,
>
> My query limit is exceeding the 1024 URL length. Can I configure solr to
> accept POST requests while searchi
Hi,
My query limit is exceeding the 1024 URL length. Can I configure solr to
accept POST requests while searching content in solr?
Thanks in advance,
Sunil.
Could this idea of a "computed field" actually just be a query
filter? Can the filter just add a field on the return like this?
On Tue, Aug 19, 2008 at 9:10 AM, Ian Connor <[EMAIL PROTECTED]> wrote:
> I was thinking more that it would be an extra field you get back. My
> understanding of doing up
Hi Alex,
Do you think I could then specify an order on the returned fields for
each document, without reordering the fields by parsing the SOLR response ?
Thanks,
Pierre
Alexander Ramos Jardim a écrit :
Hey Pierre,
I don't know if my case helps you, but what I do to keep relational
informat
I was thinking more that it would be an extra field you get back. My
understanding of doing updates requires:
1. get your document (either by ID or from a search)
2. merge your update into the doc
3. update solr with the doc (which essentially just writes it all
again but as you have done the merg
On Aug 19, 2008, at 8:49 AM, Ian Connor wrote:
What is the current "special requestHandler" that you can set
currently?
If you're referring to my issue post, that's just something we have
internally (not in trunk solr) that we use instead of /update -- it
just inserts a hostname:port/sol
What is the current "special requestHandler" that you can set currently?
On Tue, Aug 19, 2008 at 8:41 AM, Shalin Shekhar Mangar
<[EMAIL PROTECTED]> wrote:
> There's an issue open for this. Look at
> https://issues.apache.org/jira/browse/SOLR-705
>
> On Tue, Aug 19, 2008 at 6:08 PM, Ian Connor <[EM
There's an issue open for this. Look at
https://issues.apache.org/jira/browse/SOLR-705
On Tue, Aug 19, 2008 at 6:08 PM, Ian Connor <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there a way to know which shard contains a given result. This would
> help when you want to write updates back to the correct p
Hi,
Is there a way to know which shard contains a given result. This would
help when you want to write updates back to the correct place.
The idea is when you read your results, there would be an item to say
where a given result came from.
--
Regards,
Ian Connor
From: http://www.nabble.com/CHANGES.txt-td18901774.html
The latest version of solr-ruby is 0.0.6:
solr-ruby-0.0.6.gem
http://rubyforge.org/frs/?group_id=2875&release_id=23885
I think it isn't clear what Solr version is corresponding.
I'd like to change this to solr-ruby-{solrVersion}.{solr-ruby
On Tue, Aug 19, 2008 at 4:50 AM, Jon Drukman <[EMAIL PROTECTED]> wrote:
> Jon Drukman wrote:
>
>> I just migrated my solr instance to a new server, running RHEL5.2. I
>> installed java from yum but I suspect it's different from the one I used to
>> use.
>>
>
>
> Turns out my instincts were correc
28 matches
Mail list logo
