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 0C592184D3 for ; Wed, 6 Jan 2016 15:57:32 +0000 (UTC) Received: (qmail 99512 invoked by uid 500); 6 Jan 2016 15:57:29 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 99434 invoked by uid 500); 6 Jan 2016 15:57:29 -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 99422 invoked by uid 99); 6 Jan 2016 15:57:29 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jan 2016 15:57:29 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A587518048D for ; Wed, 6 Jan 2016 15:57:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.879 X-Spam-Level: ** X-Spam-Status: No, score=2.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id vVGkyHFbFPhG for ; Wed, 6 Jan 2016 15:57:27 +0000 (UTC) Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 17BFB231B8 for ; Wed, 6 Jan 2016 15:57:27 +0000 (UTC) Received: by mail-vk0-f50.google.com with SMTP id k1so158394152vkb.2 for ; Wed, 06 Jan 2016 07:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wgdCBxLdTfLfgpn7Dvj1LeYPbl1sOPJkQJhy453kWCs=; b=djGAWhj0S4Ds2fU2nwIYLCSwfSW4ywosomexKGHsMQ8pi+yA6CgofnT2RvQVscC3hq j2VR9qYi/GSut5B2euBL96gg745dk72Fw9RGDcOzlx6lJiyHtnwBCk0OjeJm8pAOVA+Y YRDLvFSqUMpbzLLgqBRShH79odzYHYkZ/gfKxV2ZAhFcyhJN1wbvOQA2CYj2fNstqYR2 TJFvj/B9bSW9M6t+E0EjMBbgFJ4OQzuBYeG1sjHQHr3BIa8fFvkYip3Y4gKVGy2JysOy pwKJRwWXZhvSYm/PoCRhhY+pqzXKfFmisv6K5UK7+FYMBRSW5ws5j1+ojXeCtthzpc5F MN3Q== MIME-Version: 1.0 X-Received: by 10.31.8.72 with SMTP id 69mr70286972vki.145.1452095846331; Wed, 06 Jan 2016 07:57:26 -0800 (PST) Received: by 10.31.47.137 with HTTP; Wed, 6 Jan 2016 07:57:26 -0800 (PST) In-Reply-To: References: <253780466.396051.1451907438051.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 6 Jan 2016 10:57:26 -0500 Message-ID: Subject: Re: Query behavior difference. From: Jack Krupansky To: solr-user@lucene.apache.org Content-Type: multipart/alternative; boundary=001a1145508019bb320528ac6969 --001a1145508019bb320528ac6969 Content-Type: text/plain; charset=UTF-8 The motivation for the constant-score rewrite is simply performance. As per the Javadoc: "*This method is faster than the BooleanQuery rewrite methods when the number of matched terms or matched documents is non-trivial. Also, it will never hit an errant BooleanQuery.TooManyClauses exception.*" So that's a second reason - to avoid the max clause count limitation of Boolean Query. See: https://lucene.apache.org/core/5_4_0/core/org/apache/lucene/search/MultiTermQuery.html#CONSTANT_SCORE_REWRITE https://lucene.apache.org/core/5_4_0/core/org/apache/lucene/search/WildcardQuery.html -- Jack Krupansky On Wed, Jan 6, 2016 at 6:07 AM, Modassar Ather wrote: > Please help me understand why queries like wildcard, prefix and few others > are re-written into constant score query? > Why the scoring factors are not taken into consideration in such queries? > > Please correct me if I am wrong that this behavior is per the query type > irrespective of the parser used. > > Thanks, > Modassar > > On Wed, Jan 6, 2016 at 12:56 PM, Modassar Ather > wrote: > > > Thanks for your response Ahmet. > > > > Best, > > Modassar > > > > On Mon, Jan 4, 2016 at 5:07 PM, Ahmet Arslan > > wrote: > > > >> Hi, > >> > >> I think wildcard queries fl:networ* are re-written into Constant Score > >> Query. > >> fl=*,score should returns same score for all documents that are > retrieved. > >> > >> Ahmet > >> > >> > >> > >> On Monday, January 4, 2016 12:22 PM, Modassar Ather < > >> modather1981@gmail.com> wrote: > >> Hi, > >> > >> Kindly help me understand how will relevance ranking differ int > following > >> searches. > >> > >> query : fl:network > >> query : fl:networ* > >> > >> What I am observing that the results returned are different in both of > >> them > >> in a way that the top documents returned for q=fl:network is not present > >> in > >> the top results of q=fl:networ*. > >> For example for q=fl:network I am getting top documents having around 20 > >> occurrence of network whereas the top result of q=fl:networ* has only > >> couple of occurrence of network. > >> I am aware of the underlying normalization process participation in > >> relevance ranking of documents but not able to understand such a > >> difference > >> in the ranking of result for the queries. > >> > >> Thanks, > >> Modassar > >> > > > > > --001a1145508019bb320528ac6969--