To: solr-user
Sent: Fri, Aug 22, 2014 8:15 am
Subject: RE: Incorrect group.ngroups value
The Co-location section of this document
http://searchhub.org/2013/06/13/solr-cloud-document-routing/
might be of interest to you. It mentions the need for using Solr Cloud routing
to group documents in
; --Andrew Shumway
>
>
> -Original Message-
> From: Bryan Bende [mailto:bbe...@gmail.com]
> Sent: Friday, August 22, 2014 9:01 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Incorrect group.ngroups value
>
> Thanks Jim.
>
> We've been using the composi
Message-
From: Bryan Bende [mailto:bbe...@gmail.com]
Sent: Friday, August 22, 2014 9:01 AM
To: solr-user@lucene.apache.org
Subject: Re: Incorrect group.ngroups value
Thanks Jim.
We've been using the composite id approach where we put group value as the
leading portion of the id (i.e. group
Thanks Jim.
We've been using the composite id approach where we put group value as the
leading portion of the id (i.e. groupValue!documentid), so I was expecting
all of the documents for a given group to be in the same shard, but at
least this gives me something to look into. I'm still suspicious
Hi Bryan,
This is a known limitations of the grouping.
https://wiki.apache.org/solr/FieldCollapsing#RequestParameters
group.ngroups:
*WARNING: If this parameter is set to true on a sharded environment, all
the documents that belong to the same group have to be located in the same
shard, otherwis
Is there any known issue with using group.ngroups in a distributed Solr
using version 4.8.1 ?
I recently upgraded a cluster from 4.6.1 to 4.8.1, and I'm noticing several
queries where ngroups will be more than the actual groups returned in the
response. For example, ngroups will say 5, but then th
