Return-Path: Delivered-To: apmail-lucene-general-archive@www.apache.org Received: (qmail 46146 invoked from network); 9 Dec 2010 13:20:49 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Dec 2010 13:20:49 -0000 Received: (qmail 12800 invoked by uid 500); 9 Dec 2010 13:20:49 -0000 Delivered-To: apmail-lucene-general-archive@lucene.apache.org Received: (qmail 12594 invoked by uid 500); 9 Dec 2010 13:20:48 -0000 Mailing-List: contact general-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@lucene.apache.org Delivered-To: mailing list general@lucene.apache.org Received: (qmail 12586 invoked by uid 99); 9 Dec 2010 13:20:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Dec 2010 13:20:48 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [85.25.71.29] (HELO mail.troja.net) (85.25.71.29) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Dec 2010 13:20:40 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id ABCC3D36007 for ; Thu, 9 Dec 2010 14:20:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.troja.net Received: from mail.troja.net ([127.0.0.1]) by localhost (megaira.troja.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+g6BTfqMspD for ; Thu, 9 Dec 2010 14:20:16 +0100 (CET) Received: from VEGA (WDC-MARE.marum.de [134.102.249.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTPSA id E7E23D36004 for ; Thu, 9 Dec 2010 14:20:15 +0100 (CET) From: "Uwe Schindler" To: References: <1291790699063-2038419.post@n3.nabble.com> <024e01cb9719$d6dceb10$8496c130$@thetaphi.de> <1291896416219-2057294.post@n3.nabble.com> In-Reply-To: <1291896416219-2057294.post@n3.nabble.com> Subject: RE: FieldCacheRangeFilter Vs NumericRangeQuery Date: Thu, 9 Dec 2010 14:20:59 +0100 Message-ID: <02b601cb97a3$ebf13cb0$c3d3b610$@thetaphi.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQIZ4N2HzXtalasbjJ5rljcgbEGPnwHvjrm7AfOf9dKS3GrDsA== Content-Language: de > Hi, > I run search using FieldChacheFilter and NumericRangeFilter and i am > getting the similar results. Searchtime is same in both the cases. My index > size is 10000000 documents. > My point is : > > 1. When search is performed using FieldCacheFilter then it caches the first > query search result and so next query searches becomes fast. But its not the > case with NumericRangeFilter then Why i am getting the same search time in > both implementations. It does not cache the filter result unless you use CachingWrapperFilter. It caches only the actual values for each document in the FieldCache but that has nothing to do with Filters at all. But it must still review all values for all documents in the FieldCache to filter the documents. This is faster for lots of documents matching the query, but for very sparse result sets this is too expensive. NumericRangeFilter works different, but for it to work, you have to use a non-infinite precisionStep during indexing with NumericField, so the index gets bigger. If you only use FieldCacheRangeFilter, you can index with precisionStep=Integer.MAX_VALUE (see docs). I posted you this article, it explains all of this: http://s.apache.org/tk > 2. I want to know in which case i should use filters. I am performing searches > on DateRanges. User just enters a date to search the required document, will > it b benificial to use filter in this case. > As far as i know filters should use when u want to apply some constraints( eg. > hide documents which are of "high security") , but in my case too seaching is > very fast in case of filter. Should i really use filter? Since recent versions of Lucene, there is no difference for MultiTermQueries like NumericRangeQuery, TermRangeQuery,... and replacing them by a filter. The pro for filters is just for the case where you want to cache them (e.g. NumericRangeFilter, FieldCacheRangeFilter,...) for later reuse. But for user-entered arbitrary queries this is not needed and Filters are as fast as Queries, sometimes the Queries are even faster (this has internal reasons because of a missing optimization in IndexSearcher). Uwe