On Tue, Mar 10, 2015 at 7:09 PM, Timothy Potter
wrote:
> So I guess my question is why doesn't the non-distrib query do
> de-duping?
>
Tim,
that's by design behavior. the special _root_ field is used as a delete
term when a block update is applied i.e in case of block, is
not used. see
https://
We've seen this as well. Before we understood the cause, it seemed very
bizarre that hitting different nodes would yield different numFound, as
well as using different rows=N (since the proxying node only de-dupe the
documents that are returned in the response).
I think "consistency" and "correctn
t;
> - Original Message
> > From: Marcus Herou <[EMAIL PROTECTED]>
> > To: solr-user@lucene.apache.org
> > Sent: Thursday, June 12, 2008 3:17:52 PM
> > Subject: Re: Num docs
> >
> > Cacti, Nagios you name it already in use :)
> >
> > Well I
52 PM
> Subject: Re: Num docs
>
> Cacti, Nagios you name it already in use :)
>
> Well I'm the CTO so the one really really interested in estimating perf.
>
> The id's come from a db initially and is later used for retrieval from a
> distributed on disk caching
Nutch
>
>
> - Original Message
> > From: Marcus Herou <[EMAIL PROTECTED]>
> > To: solr-user@lucene.apache.org
> > Sent: Tuesday, June 10, 2008 3:29:40 PM
> > Subject: Re: Num docs
> >
> > Well guys you are right... Still I want to hav
: Re: Num docs
> > >
> > > I even think that such a decision should be based on the overall machine
> > > performance at a given time, and not the index size. Unless you are
> > talking
> > > solely about HD space and not having any performance is
s, CPU speed, FSB, RAM, etc.),
> > performance numbers, etc. and come up with a number for each server's
> > overall capacity.
> >
> >
> > As a matter of fact, I think this would be useful to have right in Solr,
> > primarily for use when allocating and
m/ -- Lucene - Solr - Nutch
>
>
> - Original Message
> > From: Alexander Ramos Jardim <[EMAIL PROTECTED]>
> > To: solr-user@lucene.apache.org
> > Sent: Monday, June 9, 2008 6:42:17 PM
> > Subject: Re: Num docs
> >
> > I even think that such a de
gt; To: solr-user@lucene.apache.org
> Sent: Monday, June 9, 2008 6:42:17 PM
> Subject: Re: Num docs
>
> I even think that such a decision should be based on the overall machine
> performance at a given time, and not the index size. Unless you are talking
> solely about HD space and not having an
that you can rely on du, vmstat, iostat, top and such, too. :)
>
> Otis
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>
> - Original Message
> > From: Marcus Herou <[EMAIL PROTECTED]>
> > To: solr-user@lucene.apache.org
> >
This appears in the stats.jsp page. Both the total of document 'slots' and
the number of live documents.
-Original Message-
From: Marcus Herou [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 07, 2008 2:09 AM
To: solr-user@lucene.apache.org
Subject: Num docs
Hi.
Is there a way of retrieve
008 12:33:10 PM
> Subject: Re: Num docs
>
> Thanks, I wanna ask the indices how much more each shard can handle before
> they're considered "full" and scream for a budget to get a new machine :)
>
> /M
>
> On Sat, Jun 7, 2008 at 3:07 PM, Otis Gospodnetic
>
Thanks, I wanna ask the indices how much more each shard can handle before
they're considered "full" and scream for a budget to get a new machine :)
/M
On Sat, Jun 7, 2008 at 3:07 PM, Otis Gospodnetic <[EMAIL PROTECTED]>
wrote:
> Marcus, check out the Luke request handler. You can get it from i
Marcus, check out the Luke request handler. You can get it from its output.
It may also be possible to get *just* that number, but I'm not looking at
docs/code right now to know for sure.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: M
14 matches
Mail list logo
