https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
Distributed queries:
curl 'http://devxen0:8983/solr/core0/select?
shards=search3:0,search3:8983/solr/
core2&version=2.2&start=0&rows=10&q=instance%3Arit%5C-
csm.symplicity.com+AND+label%3ALogin&wt=php'
curl 'http://devxen0:8983/solr/core0/select?
shards=search3:0,search3:8983/solr/
core2&v
thread and enough disk.
wunder
On 11/3/08 2:58 PM, "Alok Dhir" <[EMAIL PROTECTED]> wrote:
I was afraid of that. Was hoping not to need another big fat box
like
this one...
---
Alok K. Dhir
Symplicity Corporation
www.symplicity.com
(703) 351-0200 x 8080
[EMAIL PROTECTED]
On N
configuration
comes in handy. Commits to the Master don't slow down queries on the
Slave.
-Todd
-Original Message-
From: Alok Dhir [mailto:[EMAIL PROTECTED]
Sent: Monday, November 03, 2008 1:47 PM
To: solr-user@lucene.apache.org
Subject: SOLR Performance
We've moved past this issue b
; in search performance.
I'd appreciate any suggestions.
---
Alok K. Dhir
Symplicity Corporation
www.symplicity.com
(703) 351-0200 x 8080
[EMAIL PROTECTED]
On Oct 29, 2008, at 4:30 PM, Alok Dhir wrote:
Hi -- using solr 1.3 -- roughly 11M docs on a 64 gig 8 core machine.
Fairly simple schem
We have implemented the suggested reduction in granularity by dropping
time altogether and simply disallowing time filtering. This, in light
of other search filters we have provided, should prove be sufficient
for our user base.
We did keep the fine granularity field not for filtering, but
timestamp values to go through.
On Wed, Oct 29, 2008 at 1:30 PM, Alok Dhir <[EMAIL PROTECTED]>
wrote:
Hi -- using solr 1.3 -- roughly 11M docs on a 64 gig 8 core machine.
Fairly simple schema -- no large text fields, standard request
handler. 4
small facet fields.
The index is an
Hi -- using solr 1.3 -- roughly 11M docs on a 64 gig 8 core machine.
Fairly simple schema -- no large text fields, standard request
handler. 4 small facet fields.
The index is an event log -- a primary search/retrieval requirement is
date range queries.
A simple query without a date rang
clauses in not the results -- its what you're sending in as the
query. apparently it's larger than 1024 clauses...
On Oct 10, 2008, at 5:41 PM, Choi, David wrote:
Hi everyone, I have a (hopefully) basic question..
Does solr have a max. limit on the number of returned results?
I get the foll
Check again that you put the index directory in the right place. If
you're using the example config which comes with the release package,
it needs to be in BASE/example/solr/data/index.
On Oct 8, 2008, at 8:18 AM, dudes dudes wrote:
hi again,
I guess I'm doing something wrong,
I have
I've upgraded solr several times from nightly to nightly and then to
the 1.3 release without reindexing, with no apparent ill effects.
On Oct 8, 2008, at 6:12 AM, dudes dudes wrote:
Hello all,
I would like to upgrade to the latest Solr from its nightly version.
MY understanding is to re-in
ually that the index is updated (via
commit()--autoCommit will not work).
-Mike
On 26-Feb-08, at 9:39 AM, Alok Dhir wrote:
Are you saying all the servers will use the same 'data' dir? Is
that a supported config?
On Feb 26, 2008, at 12:29 PM, Matthew Runo wrote:
We're ab
Hey Matt - congratulations on your new site -- it looks great.
I'm curious, after a few weeks of having run this way, what your
findings are regarding running the shared index on NFS. Any problems
as of yet?
I assume you're indexing from one machine and calling 'commit' on the
others on
is this going to go into the 1.3 tree at some point?
On Feb 27, 2008, at 3:25 PM, Sean Timm wrote:
Take a look at https://issues.apache.org/jira/browse/SOLR-236 Field
Collapsing.
-Sean
Head wrote:
I would like to be able to tell SOLR to dedup the results based on
a certain
set of fields.
Are you saying all the servers will use the same 'data' dir? Is that
a supported config?
On Feb 26, 2008, at 12:29 PM, Matthew Runo wrote:
We're about to do the same thing here, but have not tried yet. We
currently run Solr with replication across several servers. So long
as only one serv
Missed one bit of data: This dataset will be searched less than 500
times per day. The goal is to get results in a reasonable amount of
time (<3s), but the queries coming in per minute will likely max out
around 10.
On Dec 28, 2007, at 3:36 PM, Alok Dhir wrote:
Hey all -- first, tha
Hey all -- first, thanks to the solr & lucene teams for fantastic
products. So far we're very pleased with the results we're seeing
from them. We're looking at it as the primary search solution for a
rather large dataset. Hoping for a comments/sanity check from people
who "know".
Looki
17 matches
Mail list logo
