Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E1F14181F2 for ; Sat, 16 Jan 2016 11:15:47 +0000 (UTC) Received: (qmail 69402 invoked by uid 500); 16 Jan 2016 11:15:44 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 69338 invoked by uid 500); 16 Jan 2016 11:15:44 -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 69327 invoked by uid 99); 16 Jan 2016 11:15:44 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Jan 2016 11:15:44 +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 D0E621A01E8 for ; Sat, 16 Jan 2016 11:15:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-0.554] autolearn=disabled Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 1O6KuOD34KAm for ; Sat, 16 Jan 2016 11:15:42 +0000 (UTC) Received: from sbexch04.sb.statsbiblioteket.dk (sbexch04.sb.statsbiblioteket.dk [130.225.24.70]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 41D674293A for ; Sat, 16 Jan 2016 11:15:42 +0000 (UTC) Received: from sbexch04.sb.statsbiblioteket.dk (130.225.24.70) by sbexch04.sb.statsbiblioteket.dk (130.225.24.70) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 16 Jan 2016 12:15:40 +0100 Received: from sbexch04.sb.statsbiblioteket.dk ([fe80::84ce:82da:4b03:e7d4]) by sbexch04.sb.statsbiblioteket.dk ([fe80::84ce:82da:4b03:e7d4%14]) with mapi id 15.00.1130.005; Sat, 16 Jan 2016 12:15:40 +0100 From: Toke Eskildsen To: solr_user lucene_apache Subject: Re: &fq degrades qtime in a 20million doc collection Thread-Topic: &fq degrades qtime in a 20million doc collection Thread-Index: AQHRTlDorajvDNw+fEKXBQgblDYb0J76D/MAgAMRBgCAADGyAIAAowJL Date: Sat, 16 Jan 2016 11:15:39 +0000 Message-ID: <1452942939774.23223@statsbiblioteket.dk> References: <1452722508554-4250567.post@n3.nabble.com> <5696E546.4080301@elyograg.org> ,<1452908924619-4251212.post@n3.nabble.com> In-Reply-To: <1452908924619-4251212.post@n3.nabble.com> Accept-Language: en-GB, da-DK, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [188.183.66.166] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Anria B. wrote:=0A= > Schema investigations : the &fq are frequently on Multivalued string=0A= f> ields, and we believe that it may also be slowing down the &Fq even more= ,=0A= > but we were wondering why. When we run &fq on single valued fields its= =0A= > faster than the multi-valued fields, even when the multi-valued fields=0A= > frequently have only a single value in it.=0A= =0A= To my knowledge there should not be a difference per se. In both cases the = underlying lookup structure is term->docIDs. Could it be that there are jus= t more terms in your multi-valued fields or that they match more documents?= =0A= =0A= - Toke Eskildsen=0A=