Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 71022 invoked from network); 10 Aug 2007 19:34:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Aug 2007 19:34:13 -0000 Received: (qmail 84837 invoked by uid 500); 10 Aug 2007 19:34:05 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 84797 invoked by uid 500); 10 Aug 2007 19:34:05 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 84784 invoked by uid 99); 10 Aug 2007 19:34:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2007 12:34:05 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [194.109.24.26] (HELO smtp-vbr6.xs4all.nl) (194.109.24.26) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2007 19:34:04 +0000 Received: from k8l.lan (porta.xs4all.nl [80.127.24.69]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id l7AJXe3k010673 for ; Fri, 10 Aug 2007 21:33:41 +0200 (CEST) (envelope-from paul.elschot@xs4all.nl) From: Paul Elschot To: java-user@lucene.apache.org Subject: Re: scorers and filters Date: Fri, 10 Aug 2007 21:33:40 +0200 User-Agent: KMail/1.8.2 References: <8837fb770708101048m6f524bc6w3931ca8c8f190775@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708102133.40433.paul.elschot@xs4all.nl> X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Checked: Checked by ClamAV on apache.org On Friday 10 August 2007 20:27, Yonik Seeley wrote: > On 8/10/07, John Wang wrote: > > Hi Lucene Gurus: > > > > More of a performance question: > > > > When you pass a Filter to a searcher to do a search, the searcher is > > basically doing the full search and then intersect against the bitset given > > by the filter. This seems wasteful when there are lotsa hits returned by the > > scorer and filter only has only a few docs, e.g. > > > > Running a MatchAllDocsQuery given a Filter with only 1 doc. > > > > Right now Scorers don't know about filters, only the searchers do. And > > scorers are doing most of the computation, but it seems scorers should make > > use of the filters as the corpus before doing any score computation. > > > > Seems to me this is an area that deserves some attention. Yet another way to formulate the need for a common superclass. The patch at the issue indicated below is an "extract superclass" refactoring. And the latest discussion on it is on java-dev today. Regards, Paul Elschot. > > Skip based on the filter and the query... > See the comments in FilteredQuery, and see > https://issues.apache.org/jira/browse/LUCENE-584 > > -Yonik > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-user-help@lucene.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org