Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 49694 invoked from network); 7 Feb 2009 18:28:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2009 18:28:26 -0000 Received: (qmail 92932 invoked by uid 500); 7 Feb 2009 18:28:19 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 92884 invoked by uid 500); 7 Feb 2009 18:28:19 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 92875 invoked by uid 99); 7 Feb 2009 18:28:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Feb 2009 10:28:19 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.190.230.99] (HELO mail.troja.net) (80.190.230.99) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Feb 2009 18:28:10 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id 975824EF2F; Sat, 7 Feb 2009 19:27:49 +0100 (CET) Received: from mail.troja.net ([127.0.0.1]) by localhost (cyca.troja.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30785-10; Sat, 7 Feb 2009 19:27:48 +0100 (CET) Received: from VEGA (port-83-236-62-11.dynamic.qsc.de [83.236.62.11]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTP id E602F4EBAE; Sat, 7 Feb 2009 19:27:47 +0100 (CET) From: "Uwe Schindler" To: , References: <0A00338070614CD895159FB9760703BB@VEGA> Subject: RE: TrieRange Date: Sat, 7 Feb 2009 19:27:48 +0100 Message-ID: <45F1F93A5C284ABA8A34BD4303BF4B72@VEGA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcmJTMAWPwGiz2gpT2STLS4s7WLuZQABHLUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Checked: Checked by ClamAV on apache.org > On Sat, Feb 7, 2009 at 12:29 PM, Uwe Schindler wrote: > > This is only a minimal optimization, suitable for very large indexes. > The > > problem is: if you have many terms in highest precission (a lot of > different > > double values), seeking is more costly if you jump from higher to lower > > precisions. > > That's my point... in very large indexes this should not result in any > difference at all on average because the terms would be no where near > each other. OK. -- I prepare a new TrieRangeFilter implementation, just taking the String[] fieldnames and the sortableLong and the precisionStep. And I think, you are right. One could completely remove the "storeing" API. If one wants to add stored fields, he could use NumberUtils. > As an example: in a very big index, one wants to independently collect > all documents that match "apple" and all documents that match "zebra", > which term you seek to first should not matter. OK, I agree :) Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org