Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id F21DF200D39 for ; Sat, 11 Nov 2017 18:17:49 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id F08FF160C03; Sat, 11 Nov 2017 17:17:49 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 1C93B1609E5 for ; Sat, 11 Nov 2017 18:17:48 +0100 (CET) Received: (qmail 24123 invoked by uid 500); 11 Nov 2017 17:17:47 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 24111 invoked by uid 99); 11 Nov 2017 17:17:46 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Nov 2017 17:17:46 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 2D2EF1A174A for ; Sat, 11 Nov 2017 17:17:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.98 X-Spam-Level: * X-Spam-Status: No, score=1.98 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=ontoforce-com.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id XRJQnAgJvvT5 for ; Sat, 11 Nov 2017 17:17:44 +0000 (UTC) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id D5A195F29A for ; Sat, 11 Nov 2017 17:17:43 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id s144so8268047oih.3 for ; Sat, 11 Nov 2017 09:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ontoforce-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0Xm8dIZsE1s5XGptWkedEj8gkm8eux0tsz7PuDWOviE=; b=v59/8XbpMsXCYMHIy+/tRgFUESkOTCi4N7+F/KB8knLZsaeYBbHnDHjsbeDCaFoQeB 2F/v837Gf4FULlEPmH24M72NTUghncj2h2TeTnA6AbAoDdAV9RmgUbvqx1znrbLQIxwE h9opoRUMj7C/3YaUEpCexCEanHdWGee+TdC4qp54ecd8dzI5OeHKPIebUh695nvRcI5S CLGRsdYoHIypGcOWeyW06YfMg9kjCFFSorWhyKW6H58/mUorOmeRetyZIui5sqJBGuf0 C8nidvVnhXTKofDH6mN3JQzq4sOgsc6Kolpgf9zQS6VgyviMSYr0fRKfkCfs2+zj2tJz 1BuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=0Xm8dIZsE1s5XGptWkedEj8gkm8eux0tsz7PuDWOviE=; b=pu8CMj8NE79kQso4SlTcOKBdM7OYplNYhPThTa1hjTVf7q0AHCOAZ2XyfHYFV2PkMb 41cWGZA/WE2oYwV0unZI9V7uGtxuV0AlPz1uc0NpsSLSxy6xdCZaPSAI8TJe0TPUt/VM TpJbrSokp3zm0uzqE+7vnCFWj8FcOocnB9OSGG0nEgdpu739vvxXDCDfaTwE0t7wr3ZO Ql6jrZ6rGUVSrB3Uff5oaSFaP5ETQt+FwPV98J+19wfke+uWaDexEX39DWIi/jV43StN bmNQI2bh/HnN/P7bN1caGKUUZWImjPLc81kUlemVva4u9YOsJRFqoRNDCURiamV9lLSa BRow== X-Gm-Message-State: AJaThX5j+cJzpnfYkjXO5L4yWAFpFv++mUWHgk/m+HOZRU73VDJWoT4x Yu52a6wdkItXVfEc8Cewxm9LfTV7vGgqXcKxbvVFY48w X-Google-Smtp-Source: AGs4zMZJdRApja1R7P5EGrdeRGjy3Gh1v1mrhpQlhLR2mjqAFV6brbM6R2FqPapgIn7H+lWCllHMEaR1ndrwupSTchE= X-Received: by 10.202.207.193 with SMTP id f184mr2212335oig.65.1510420662937; Sat, 11 Nov 2017 09:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.156.8 with HTTP; Sat, 11 Nov 2017 09:17:22 -0800 (PST) In-Reply-To: References: <16b842da-04dd-857a-09da-4456cd2bcd06@ontoforce.com> From: Kenny Knecht Date: Sat, 11 Nov 2017 18:17:22 +0100 Message-ID: Subject: Re: Nested facet complete wrong counts To: solr-user@lucene.apache.org Content-Type: multipart/related; boundary="001a113df35a1403dd055db8370d" archived-at: Sat, 11 Nov 2017 17:17:50 -0000 --001a113df35a1403dd055db8370d Content-Type: multipart/alternative; boundary="001a113df35a1403db055db8370c" --001a113df35a1403db055db8370c Content-Type: text/plain; charset="UTF-8" AAAARRGG - [banging my head against the wall] Of course. You are abolutely right about the multi valuedness Thanks for the 7.0 hint. Gives a reason to upgrade. Need to re-index when upgrading? Kenny [image: ONTOFORCE] Kenny Knecht, PhD CTO and technical lead +32 486 75 66 16 <0032498464291> kenny@ontoforce.com www.ontoforce.com Meetdistrict, Ottergemsesteenweg-Zuid 808, 9000 Gent, Belgium CIC, One Broadway, MA 02142 Cambridge, United States On 11 November 2017 at 15:52, Yonik Seeley wrote: > Also, If you're looking at all constraints, you shouldn't need refine:true > But if you do need it, it was only added in Solr 7.0 (and I see you're > using 6.6) > > -Yonik > > > On Sat, Nov 11, 2017 at 9:48 AM, Yonik Seeley wrote: > > On Sat, Nov 11, 2017 at 9:18 AM, Kenny Knecht > wrote: > >> Hi Yonik, > >> > >> I am aware of the estimate on the hll. But we don't use the hll as a > >> baseline for comparison. We ask the values for one facet (for example > >> Gender). We store these counts for each bucket. Next we do another > request. > >> This time for a facet and a subfacet (for example Gender x Type). We sum > >> all the values of Type with the same Gender and compare these sums with > the > >> numbers of previous request. These numbers differ by 60% which is quite > >> worrying. Not always it depends on the facet, but still. > >> Did you get any reports like this? > > > > Nope. The counts for the scenario you describe should add up exactly > > for single-valued fields. Are you sure you're adding in the "missing" > > bucket? > > > > When you some up the sub-facets on Type, do you get a value under or > > over the counts on the parent facet? > > Verify that Type is single-valued. One would not expect facets on a > > multi-valued field to add up in the same way. > > Verify that you're getting all of the Type constraints by using a > > limit of -1on that sub-facet. > > > > -Yonik > --001a113df35a1403db055db8370c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
AAAARRGG - [banging my head against th= e wall]
Of course. You are abolutely right about the multi valuedn= ess
Thanks for the 7.0 hint. Gives a reason to upgrade.
N= eed to re-index when upgrading?

Kenny


=20 =20 =20 =20
=3D"ONTOFORCE"
Kenny Knecht, PhD
CTO and technical lead
+32 486 75 66 16
kenny@ontoforce.com
www.ontoforce.com
=20 =20 =20 Meetdistrict, Ottergemsesteenweg-Zuid 808, 9000 Gent, Belgium
CIC, One Broadway, MA 02142 Cambridge, United States

On 11 November 2017 at 15:52, Yonik Seeley <= span dir=3D"ltr"><yseeley@gmail.com> wrote:
= Also, If you're looking at all constraints, you shouldn't need refi= ne:true
But if you do need it, it was only added in Solr 7.0 (and I see you're<= br> using 6.6)

-Yonik


On Sat, Nov 11, 2017 at 9:48 AM, Yonik Seeley <yseeley@gmail.com> wrote:
> On Sat, Nov 11, 2017 at 9:18 AM, Kenny Knecht <kenny@ontoforce.com> wrote:
>> Hi Yonik,
>>
>> I am aware of the estimate on the hll. But we don't use the hl= l as a
>> baseline for comparison. We ask the values for one facet (for exam= ple
>> Gender). We store these counts for each bucket. Next we do another= request.
>> This time for a facet and a subfacet (for example Gender x Type). = We sum
>> all the values of Type with the same Gender and compare these sums= with the
>> numbers of previous request. These numbers differ by 60% which is = quite
>> worrying. Not always it depends on the facet, but still.
>> Did you get any reports like this?
>
> Nope.=C2=A0 The counts for the scenario you describe should add up exa= ctly
> for single-valued fields.=C2=A0 Are you sure you're adding in the = "missing"
> bucket?
>
> When you some up the sub-facets on Type, do you get a value under or > over the counts on the parent facet?
> Verify that Type is single-valued.=C2=A0 One would not expect facets o= n a
> multi-valued field to add up in the same way.
> Verify that you're getting all of the Type constraints by using a<= br> > limit of -1on that sub-facet.
>
> -Yonik

--001a113df35a1403db055db8370c-- --001a113df35a1403dd055db8370d--